概述WS-Security 规范互操作性问题与解决办法

　　您是否被 WS-Security 规范级别互操作性问题困扰着？Web 服务经常被视为应用程序互操作性的理想解决方案，无论平台、供应商和编程语言如何，它都能 有效地进行应用程序集成。但它们并不能彻底避免互操作性问题。本文将介绍一些由于不同 WS-Security 规范版本之间的不兼容造成的常见问题，从而找到处理您的环境中的问题的最佳方法。本文最后提供一个实用图表，对每个解决方案的好处和缺点进行了比较，务必记得阅读其中的内容。

　　互操作性问题概述

　　大部分互操作性问题都不是源自基础 Web 服务规范（这些规范已经相当成熟和稳定了），而是由于各种 WS-* Web 服务扩展规范（如 WS-Security）造成的。随着这些标准的不断发展，供应商必须选择支持哪个版本的规范，而有时候开发人员会需要处理不同规范间不兼容的问题。

　　WS-Security 标准提供了将身份验证、完整性和保密性应用到 SOAP 消息的机制。在企业中采用 Web 服务和面向服务的体系结构（Services-Oriented Architecture，SOA）时经常需要使用这些功能。从 IBM WebSphere Application Server V5.0.2 开始，IBM 中间件开始提供对 WS-Security 的支持。WS-Security 的这个实现基于 OASIS 工作草案 13 规范。WebSphere Application Server V5.1 和基于 Java 2 Platform Enterprise Edition (J2EE) 1.3 的其他 IBM 中间件（如 IBM WebSphere Portal Server V5 和 IBM WebSphere Business Integration Server Foundation V5）也包含基于草案 13 规范的 WS-Security 实现。通过 WebSphere Application Server V6.0 中包含的 J2EE 1.4 运行时，IBM 提供了基于 WS-Security 1.0 规范的 WS-Security 实现。IBM WebSphere Process Server 和使用 J2EE 1.4 运行时的其他 IBM 中间件包括基于 1.0 版规范的 WS-Security 实现。

　　不幸的是，由于 WS-Security SOAP Header 规范的连接格式的变化，符合草案 13 规范的 Web 服务使用者应用程序和目标 Web 服务并不能与符合 1.0 版规范的使用者应用程序和目标服务进行交互。例如，在 WebSphere Portal Server V5.1 中运行的 J2EE 1.3 Web 服务使用者应用程序无法使用 WS-Security 与在 WebSphere Application Server V6.0 中运行的 J2EE 1.4 服务提供者应用程序进行通信。这个问题不仅限于 IBM 中间件软件堆栈。例如，Microsoft .NET Web Services Enhancements (WSE) 1.0 也基于 WS-Security 规范的一个草案版本，当尝试在此堆栈与任何基于 WS-Security 1.0 规范的其他堆栈之间进行通信时，会出现相同的问题。

　　图 1. WS-Security 规范级别不兼容问题

　　如果遇到这种不兼容的情况，可通过多种方法解决此问题。本文剩下的部分将说明这些选项，并提供了有关如何基于业务需求和技术约束选择恰当的解决方案的指导信息。

　　为了简单起见，让我们假定 Web 服务使用者应用程序使用 WS-Security 草案 13 规范，而 Web 服务提供者应用程序使用 WS-Security 1.0 规范。注意：此处建议的解决方法也可以应用于相反的场景，即 Web 服务使用者使用 WS-Security 1.0 规范，而 Web 服务提供者使用草案 13 规范时。

　　解决方法 1：将 Web 服务使用者应用程序升级到 J2EE 1.4

　　完全避免此问题的最简单办法是，确保您的 Web 服务使用者应用程序使用相同的 WS-Security 规范版本作为您的 Web 服务提供者应用程序。这要求将您的 Web 服务使用者应用程序升级到 J2EE 1.4，另外，如果可能的话也将您的中间件升级到支持 J2EE 1.4 应用程序的版本。

　　一种开发方法是将 J2EE 1.3 Web 服务使用者应用程序升级到 J2EE 1.4。IBM Rational Application Developer 提供了 J2EE 迁移向导，该向导能够将 Enterprise JavaBeans (EJB) 项目、Web 项目、J2EE Connector Architecture (JCA) Connector 项目和 Web 服务从 J2EE 1.3 规范级别迁移到 J2EE 1.4 规范级别。

　　要使用 J2EE 迁移向导将 J2EE 1.3 应用程序迁移到 J2EE 1.4，请在 J2EE Perspective 的 Project Explorer 视图中直接右键单击 Enterprise Application 项目，然后从弹出菜单中选择 Migrate >J2EE Migration Wizard。向导完成后，可以配置 WS-Security 客户机绑定。向导并不会自动迁移这些绑定，必须在迁移完成后手动进行配置。

　　接下来，需要确保 Web 服务使用者应用程序部署到的应用服务器能够支持 J2EE 1.4 应用程序。对于企业应用程序，WebSphere Application Server V6.0 能够运行 J2EE 1.4 应用程序。而对于 Portlet，WebSphere Portal Server V5.1.0.4 能够运行迁移到 J2EE 1.4 的 Web 项目。如果采用这些或更新的版本，则经过迁移的 Web 服务使用者应用程序应该正常工作，不会出现任何问题。否则可能就需要对中间件进行升级。

　　图 2. 将 Web 服务使用者应用程序升级到 J2EE 1.4

　　表 1. 将 Web 服务使用者应用程序升级到 J2EE 1.4 时所涉及的角色和任务

　　角色 任务

　　应用程序开发人员 将 Web 服务使用者应用程序迁移到 J2EE 1.4

　　开发人员 为 Web 服务使用者应用程序设置 J2EE 1.4 操作环境

　　测试工程师 验证迁移后的 Web 服务使用者按照预期工作

　　将应用程序和（如果有必要）中间件迁移到 J2EE 1.4 是避免 WS-Security 规范级别互操作性问题的首选方法。它彻底消除了问题，并提供了在最新中间件代码级别实现的战略优势。

　　不过，根据您的应用程序和中间件环境不同，可能不方便或很难将您的 Web 服务使用者应用程序迁移到 J2EE 1.4。而且，随着必须迁移的使用 WS-Security 草案 13 规范的 Web 服务使用者应用程序的增加，实现此方法所需的工作量会直线上升。

　　解决方法 2：使用 Web Services Gateway

　　Web Services Gateway 是 IBM WebSphere Application Server Network Deployment 的一个软件组件，可以在产品安装后进行可选配置。IBM WebSphere DataPower SOAAppliances 是专门构建的一种非常易于部署的网络设备。Web Services Gateway 和 WebSphere DataPower SOAAppliances 都意在帮助简化和保护企业中的 Web 服务部署。WebSphere DataPower SOAAppliances 还可以用于提高 Web 服务应用程序的性能。

　　Web Services Gateway 或 DataPower 设备都可以用于处理 WS-Security 规范级别的互操作性问题。如图 3 中所示，这些解决方案都能够对使用 WS-Security 1.0 规范的 Web 服务进行代理，从而使得此服务对所有使用 WS-Security 草案 13 规范的 Web 服务使用者可用。

　　注意：本文剩下的部分将此解决方法称为中间件代理 方法。

　　图 3. 使用 Web Services Gateway 或 DataPower 设备

　　表 2. 使用中间件代理时所涉及的角色和任务

　　角色 任务

　　开发人员 安装 Web Services Gateway 或 DataPower 设备

　　在 Web Services Gateway 或 DataPower 设备上配置 J2EE 1.4 服务

　　测试工程师 验证 Web 服务使用者按预期工作

　　中间件代理方法的一个优势在于，不需要进行任何应用程序开发任务。Web 服务提供者和使用者应用程序无需更改就可以通过中间件代理进行互操作。由于这个原因，在有很多使用 WS-Security 草案 13 规范 Web 服务使用者需要与使用 WS-Security 1.0 规范的 Web 服务提供者进行集成时，中间件代理可方便地进行伸缩。为提供者服务安装并配置了中间件代理后，可以将其用于集成任意数量的 Web 服务使用者，而无需进行任何额外的工作。

　　此方法的另一个优势在于，可以获得使用 Web Services Gateway 或 DataPower 设备带来的所有好处。这些组件可以简化企业中的 Web 服务开发和管理，而且通过这样还能够提高您的 Web 服务应用程序和基础设施的投资回报。此外，如果选择使用 DataPower 设备，设备所提供的功能能够切实地提高您的 Web 服务应用程序的性能。有关 Web Services Gateway 和 WebSphere DataPower SOAAppliances 的好处的更多信息，请参见本文最后的参考资料部分提供的链接。

　　中间件代理方法的一个缺点是，它引入了大量操作与管理任务。必须像处理其他关键基础设施组件一样安装、配置和管理中间件代理组件。如果已经购买了 WebSphere Application Server Network Deployment Edition，则已经有了 Web Services Gateway 组件，没有必要进行额外的采购了。另一方面，如果选择使用 DataPower 设备，可能会有与此网络设备相关的成本。

　　另一个缺点是，此方法可能会破坏 Web 服务使用者与 Web 服务提供者间的信任模型。这是因为，根据所应用的安全性不同，中间件代理可能需要对使用者发送到代理的入站 SOAP 消息进行验证和加密，并对从代理发送到提供者的出站 SOAP 消息重新应用安全性。这可能对您的安全体系结构有极大的影响。

　　解决方法 3：使用 EJB 代理

　　如果要寻找轻量的低成本备选方案来替代中间件代理方法，使用 EJB 代理可能比较合适。在此方法中，将开发一个新 J2EE 1.4 EJB 应用程序并应用到前端中间件层（此层还承载 Web 服务使用者应用程序）。此方法要求前端中间件层包含 WebSphere Application Server V6.0 或更高版本，或者其他能够支持 J2EE 1.4 应用程序的 J2EE 应用服务器。

　　图 4 显示了如何使用 EJB 代理方法来允许 J2EE 1.3 门户应用程序与 J2EE 1.4 Web 服务提供者进行通信。此门户应用程序使用 EJB 的远程方法调用（Remote Method Invocation，RMI）与 EJB 代理进行通信，EJB 使用 WS-Security 1.0 规范将请求传递给 Web 服务提供者。

　　图 4. 使用 EJB 代理

　　表 3. 使用 EJB 代理方法时所涉及的角色和任务

　　角色 任务

　　应用程序开发人员 创建 EJB 代理应用程序

　　将 Web 服务使用者与 EJB 代理应用程序集成

　　部署人员 部署和管理 EJB 代理应用程序

　　测试工程师 验证 Web 服务使用者按预期工作

　　实现 EJB 代理方法所需要的工作主要是应用程序开发工作（不过此解决方法引入了另一个必须由操作团队进行部署、保护和管理的另一个应用程序）。

　　EJB 代理方法最适合沙箱、测试或概念验证场景，在此类场景下不适合选择将 Web 服务使用者应用程序升级到 J2EE 1.4，而且不能承受由设置中间件代理带来的成本。此方法的缺点是，当需要将大量使用 WS-Security 草案 13 规范的 Web 服务使用者与使用 WS-Security 1.0 版规范进行集成时，它并不能很好地扩展。在这种情况下，每个 Web 服务使用者应用程序必须与 EJB 代理分别集成，从而使必要的开发工作量变得非常大。

　　解决方法 4：添加新提供者端点

　　在最后这个方法中，要将 J2EE 1.3 Web 服务端点添加到 J2EE 1.4 提供者应用程序中。根据您的 J2EE 1.4 Web 服务提供者应用程序实现的方式不同，可能只要简单地添加基于 Java Servlet 2.2 (J2EE 1.3) 规范的 Web 项目的额外 Web 项目，并将其与提供者应用程序打包到一起即可。您的提供者应用程序此后将包含两个 Web 服务端点，如图 5 中所示。

　　图 5. 添加新提供者端点

　　表 4. 使用新提供者端点方法时所涉及的角色和任务

　　角色 任务

　　应用程序开发人员 在新 Java Servlet 2.2 Web 项目中创建新 Web 服务端点

　　将新 Web 项目打包为 J2EE 1.4 EAR 文件

　　部署人员 部署和管理 Web 服务提供者应用程序

　　测试工程师 验证 Web 服务使用者按预期工作

　　有很多 Web 服务使用者应用程序时，此方法可很好地进行扩展。修改了 Web 服务提供者应用程序，以使其提供兼容 J2EE 1.3 的 Web 服务端点后，任意数量的 Web 服务使用者应用程序都可以使用这个新端点。与 EJB 代理方法和中间件代理方法不同的是，此方法没有性能影响。

　　对于 EJB 代理方法，此解决方法主要是应用程序开发过程，引入了必须进行管理和保护的另一个 Web 服务端点。

　　此方法最适合用于 Web 服务实现类是简单的 JavaBeans 组件或 EJB 组件的情况。如果 Web 服务实现逻辑包含在 Servlet、服务组件体系结构（Service Component Architecture，SCA）组件或企业服务总线（Enterprise Service Bus，ESB）中介模块中，可能很难创建 Java Servlet 2.2 (J2EE 1.3) Web 项目并将其与 Web 服务提供者应用程序打包在一起。

　　总结

　　表 5 列出了本文中所述的三个解决方法各自的好处和缺点，可帮助您确定自己所面临的情况的最佳解决方法。

　　表 5. 解决方法好处与缺点的比较

　　方法 好处 缺点 最佳使用场合

　　将 Web 服务使用者应用程序升级到 J2EE 1.4

　　在最新的中间件和 J2EE 规范级别实现。

　　没有性能影响。

　　可伸缩能力不强；必须独立对每个 Web 服务使用者应用程序进行迁移。

　　可能还需要进行中间件迁移。

　　有些应用程序和中间件环境可能不方便和难于进行迁移。

　　当使用者应用程序的数量很小时，特别是使用者端中间件环境已经能够支持 J2EE 1.4 应用程序时。

　　使用中间件代理

　　可伸缩性很强；配置之后，代理能够支持任意数量的使用者应用程序。

　　不需要对使用者或提供者应用程序进行更改。

　　可方便地从 Web Services Gateway 或 DataPower 设备进行管理。

　　使用 DataPower 设备时可获得性能优势。

　　需要进行额外的操作和管理任务来支持新的关键基础设施组件。

　　使用 Web Services Gateway 时有一定的性能影响。

　　如果代理需要验证和加密入站 SOAP 消息并随后对出站消息重新应用安全性，可能会破坏信任模型。

　　存在大量使用者应用程序时，或无法修改使用者应用程序时。

　　使用 EJB 代理

　　实现的过程就是基本的编程操作，不需要额外的基础设施。 有一定的性能影响。

　　可伸缩性不太好；EJB 代理必须与每个使用者应用程序集成。

　　引入了必须对其进行部署、保护和管理的一个新应用程序。

　　需要用于沙箱、测试或概念验证场景的轻量低成本解决方案时。

　　添加新提供者端点

　　实现的过程就是基本的编程操作，不需要额外的基础设施。

　　没有性能影响

　　可伸缩性很强；配置之后，代理能够支持任意数量的使用者应用程序。

　　Web 服务实现逻辑不是简单的 JavaBeans 或 EJB 组件，而更为复杂时，实现并不方便。

　　引入了必须进行保护和管理的新提供者端点。

　　需要轻量级解决方案时及 Web 服务实现逻辑是 JavaBeans 或 EJB 组件时。