网关服务是单一访问点，并充当多项服务的代理。服务网关启用了跨所有服务的变换、路由和公共处理。

服务网关模块是单一调解，用于处理对多个服务使用者和提供者的请求。任何服务网关都有如下四个典型步骤：

常用处理 - 一旦网关接收到消息，就对所有消息执行常用处理，例如添加协议级的头或者记录该消息。

服务标识 - 必须将网关所处理的消息标识为特定服务类型。例如，查询消息以确定它是针对服务提供者 A、B 还是 C。

端点路由 - 当它确定某消息将传递到特定服务提供者时，它将映射到网络可寻址端点，以便可以将该消息转发到服务提供者。

特定于服务的处理 - 执行特定目标服务所需的任何处理。

用户可以根据不同的场景更改这四个步骤的顺序。

共有三个受 WebSphere® ESB 支持的现成服务网关模式：

动态服务网关模式

静态服务网关模式

代理网关模式

传统的“安全网关”、“UTM”、以及所谓的“下一代防火墙”类型的设备，大都是在防火墙的基础上叠加更多的功能，如与VPN、IDS/IPS、网关杀毒、反垃圾邮件、Web过滤等功能集成到一个硬件平台中。然而遗憾的是，这类设备在应用层安全上不尽人意，性能和功能两方面都受到了Web 2.0应用的强大压力。此类产品的应用效果普遍差强人意，要么性能上去了、功能没了，要么功能多了，性能就下来了。其根本原因在于系统架构和基于系统架构的算法对各网络层的适应性，其功能细粒度是否足够。换句话说，针对不同网络层设计的专业设备，其应用效果是最好的。

据介绍，当前主流的业务处理一般有并行和串行两种模式： 并行方式下，普通处理方式在多流多核分配时，无法保证唯一性，这需要实现智能业务并行化调度，在多核平台上保证唯一性，同时实现对多个内核资源的充分挖掘和利用。 串行方式下，需要根据各个功能模块占用系统资源不同进行相应的分配，以保证没有性能瓶颈，调理不当，就会出现多核处理器内的性能瓶颈。换言之，虽然技术上可以把第2层和第3层的数据包或数据流进行集中管理，但在应用层上的这种统一性却不尽人意。以UTM设备为例，许多部署UTM解决方案的企业和服务提供商发现，UTM设备在OSI应用层上提供安全保护做得非常差。例如，当启动UTM设备中的应用层安全功能时，用户会遭遇到相当大的性能损失，大幅度下降的网络连接性和安全检测率将会导致用户网络无法使用。