除非连接到外部世界，否则能穿越防火墙反而成为一大不利因素。

　　此外，网关需要先对文档进行解码，然后才能对之进行有效审查，因此不管采用SSL、WS-Security或SAML格式，多数网关同时也负责加密和认证。由于识别攻击要用到深度包检测技术并能理解XML，因此XML转换和路由也要用到安全网关，而且由于采用了专业化的SSL或XML加速硬件，安全网关在此方面往往优于管理软件。

　　现在，绝大多数安全网关仍是独立机箱，安装方式与传统防火墙相近，由专业厂商销售。

　　在网络中，无论安全网关以硬件还是软件的形式部署，它的作用都不仅限于阻止XML攻击。由于许多企业级SOA使用Java信息服务(JMS)，因此他们必须将之转换为HTTP格式，以通过Web发送。

　　安全网关厂商的先行者中，有4家已成为他人的囊中之物：Sarvega公司为英特尔公司(Intel)所购;NetScaler公司被思杰公司 (Citrix)收至攠下;IBM和思科公司(Cisco Systems)分别买下了DataPower公司和Reactivity公司。除了英特尔之外，其他几家现在仍然销售网关产品。英特尔则利用 Sarvega技术帮助其他厂商，围绕标准CPU而不是定制ASIC芯片开发XML软件或设备。

　　思杰的NetScaler设备集成了 XML防火墙与应用前端(AFE)。Cisco也计划将Reactivity集成到其应用控制引擎(ACE)产品线中，以达到同样的集成目标。由于AFE 位于网络边缘，而且用于加速SSL，因此，无论对于客户还是期望挺进新市场的AFE厂商而言，AFE与XML防火墙的集成都可谓意义重大。F5网络公司 (F5 Networks)也宣布将会销售自主研发的XML防火墙，而且其竞争对手很可能会步其后尘。

　　利基网络公司(Layer 7 Networks)、 Vordel公司和Xtradyne公司等其他独立安全网关厂商则与之背道而驰，以软件和虚拟化为发展方向。其中，Vordel公司和Xtradyne公司始终将其网关产品作为软件来销售，运行于专用刀片服务器环境。而且这几家公司都极推崇虚拟设备，利基网络公司和Vordel公司已开始销售运行于 VMware系统环境下的软件。

　　虚拟化的机会

　　尽管如此，虚拟设备还无法与专用服务器相提并论，这也是为什么 Vordel公司现在更关注对其虚拟软件进行测试和集成，而非产品化。利基网络公司成立伊始，就将自身定位于采用专用XML和SSL硅技术的定制设备厂商。在他们眼中，对于那些尚无法确认是否该采用专业硬件设备的小公司而言，虚拟化技术不失为一个切入点。尽管“纯软件”迄今听起来仍像是出于预算考虑的折衷之策，但很可能虚拟设备很快会应用在各种规模的企业之中。

　　虚拟机的性能在迅速提升，而且虚拟化带来的灵活性在SOA应用中有着特别的意义。由于要大量部署并再利用新服务，SOA架构需要进行调整，而借助虚拟化技术，可以迅速地将硬件设备在不同任务之间进行再分配。但是，只有其他服务器也实现虚拟化，才能共享硬件资源，而这会导致安全性问题。尽管很少见到有关VMware安全漏洞的报告，但管理多个虚拟机的工作异常复杂，因此很可能会有数据流偶尔绕过防火墙。

　　SAML和WS-Federation均将服务和认证分离。用户首先需通过某身份提供者的认证(1)，该提供者会为之提供XML凭证(2)。用户可使用此凭证再次访问一个或多个服务，而不必再次登录(3)。用户当前访问的服务，可以选择对身份提供者进行检查 (4)，以验证用户的身份(5)。在连接两家企业的Web服务中，身份提供者通常与用户位于同一家企业，而服务既可以是内部的也可以是外部的。

　　鉴于安全网关与Web服务管理软件之间存在太多的重复功能，二者目前已开始融合。DataPower公司和Reactivity公司在被收购之前均已进入管理软件市场，而且至少还有另外一家防火墙厂商也计划效仿。迄今为止，管理软件厂商尚未在其软件中添加完整的XML防火墙功能以进行反击，主要原因在于，其软件均定位在运行于整个SOA平台之上，而非边缘部分。

　　由于SSL的盛行，安全网关普遍具备SSL加速功能：甚至虚拟设备厂商也支持搭载SSL加速卡的硬件。相形之下，XML加速要罕见得多，只有利基网络公司、思科和IBM的设备采用专用XML芯片;IBM是自行研发，思科和利基网络公司用的是Tarari公司的技术。形成这种局面的部分原因在于，英特尔利用Sarvega技术帮助其他公司开发XML产品，但主要还是由于应用层加速的市场需求不足;而且，利基网络公司相信，硬件市场会逐渐过度到软件。

　　对于那些负责传输SOAP或SAML信息等较长XML文档的 Web服务来说，XML加速的价值难以言喻;而在定位于支持基于浏览器应用的Web服务中，这一技术用得不多，原因在于这类服务在每个会话中传输的数据都很少(可能只有一个XML元素或者JSON对象)，而且置于TCP/IP和HTTP包头中。由于JavaScript和Flash客户端无需为用户的每次操作刷新整个页面，因此多数Web 2.0应用中涉及的应用层数据传输，要少于用静态可扩展超文本置标语言(XHTML)开发的同类应用。

　　尽管如此，Web服务器在RIA中还占有一席之地。尽管RIA可能会减少XML传输，但他们也会极大地增加服务器需要处理的HTTP连接的数量。多数 RIA并不等待用户点击链接，而是实时运行，每隔几秒钟就需要建立新连接。而采用SSL加速和其他AFE技术，包括负载平衡和HTTP压缩在内，往往可以减轻因此而超载的服务器的负担。

　　安全标准，过犹不及？

　　在服务导向架构(SOA)领域，标准无处不在，Web服务 (WS-*)更是会继续膨胀，以影响到所有可能的简单对象访问协议(SOAP)应用案例。尽管如此，专门针对安全问题而制定的标准却屈指可数，而那些无所不包的标准则环环相扣，彼此依赖。现在，SOA领域的“物质基础”已然尘埃落定，而“上层建筑”仍在建立之中。

　　WS-Security 1.1。 描述如何将XML加密(XML Encryption)和XML签名(XML Signature)应用于SOAP文档或信息。此标准得到了所有厂商的支持，同时也被用于其他所有与安全相关的WS-*标准中。其最新版本发布于 2006年2月，很可能也是最后一个版本，因为未来的改进将被纳入其他标准。

　　WS-SecurityPolicy 1.2。对哪些人被允许访问某个服务以及访问方式做出规定，并对认证方式的类型和/或所需要的加密等级做出限制。他是Web服务策略(WS-Policy)的子集，以更为通用的方式对服务的能力和限制进行描述。此标准由国际商业机器公司(IBM)和微软公司(Microsoft)共同开发，并于2007年7月正式确立，最终将会得到所有厂商的支持。

　　WS-SecureConversation 1.3。是按照WS-Security标准，实施WS-SecurityPolicy中所描述的策略的方法。此标准于2007年3月通过审批;与此同时，IBM和太阳计算机系统公司(Sun)演示了此标准的实施过程。尽管现在鲜有客户使用此标准，Actional公司、毕益辉公司(BEA Systems)、思科公司(Cisco System)、CA公司、利基网络公司(Layer 7 Networks)、甲骨文公司(Oracle)、Reactivity公司、RSA安全公司(RSA Security)以及VeriSign公司等其他厂商也都表示支持此标准。

　　WS-Trust 1.3。 应用WS-Security标准传输密码、数字证书以及安全性断言标记语言(SAML)断言等安全标识。非SOAP Web服务与XML密钥管理规范 (XKMS)和SAML有部分相同之处。

　　WS-Federation 1.1。根据WS-SecurityPolicy中描述的服务规则，应用WS-Trust中提到的被传输的安全标识，通过Web服务的认证。由于与SAML的许多功能相同，目前尚未得到广泛应用。相较SAML，他的主要优势在于，Windows支持这一标准，而且与WS-*之间结合紧密。