实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构

    驱动 ESB 体系结构和设计决策的问题

为了确定用于 ESB 的合适解决方案模式和实现技术，需要对特定的 ESB 功能需求进行详细的分析。下面的问题旨在帮助进行这一过程，而前面的部分指出了与每个场景相关的特定问题。

1. 现有功能及其数据接口是否与您想要提供的服务相匹配？您是否能够修改或聚合应用程序？
   • 如果不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供，或者不得不由服务客户端来完成。
2. 服务是否可以以一些通用业务数据模型的形式公开？如果可以，则实现这些服务的系统是否已经支持该模型？或者说可以使它们这样做？
   • 如果服务不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供。
3. 是否需要开放标准？或者是否可以通过 EAI 中间件来实现适当的互操作性？如果需要开放标准的话，则哪些开放标准是适合的？
   • 虽然使用开放标准是实现互操作性的一种途径，但专有的 EAI 中间件也具有高度的互操作性，并且往往要成熟得多。另外，许多组织还拥有广泛的现有基础架构，在一些场景中，它们可能会使得开放标准的作用几近于无。
   • 在需要开放标准的场景中，Web 服务也许是这些情况下最明显的选择。不过，您也可以应用 Java Messaging Service (JMS)、JDBC、基本 XML 或者一些其他的技术（比如 EDI 或业界通用的 XML 格式。
   • 在实践中，不能总是假定相同标准的不同实现之间具有互操作性，特别是对于近来出现或刚刚兴起的标准。对于 Web 服务，Web 服务互操作性组织（Web Services Interoperability Organization）发布了使用 SOAP 和 WSDL 的互操作性的基本概要，其他更高级的标准（例如 Web 服务安全性（WS-Security）、Web 服务事务（WS-Transaction）等等）的概要随后也将发布。在产品全面、稳定且广泛地支持这些概要之前，开放标准的使用还没有得到保证，并且可能并不总是促进互操作性。
4. 是否需要支持基本通信协议及标准（例如 WebSphere MQ、SOAP、WSDL）？或者需要更高级的功能（例如 Web 服务安全性（WS-Security）、Web 服务事务（WS-Transaction）等等）？
   • 对支持更复杂标准的需求将对实现技术的选择加以更严格的约束，并且可能意味着使用还不成熟的技术。
5. 当果考虑更改现有的基础架构使用的消息格式和协议（包括可能采用开放标准）时，需要在整个现有的基础架构中进行这些更改吗？或者很快就要应用新的消息格式和协议吗？如果正在使用或考虑使用 EAI 技术，该技术是否有自己的内部格式？或者它能够将开放标准处理为内部格式吗？
   • 开放标准的任何应用都是受扩展访问的需求驱动的，因此它们对现有基础架构的接口的可用性比在内部使用的这样的标准更重要。
   • 如果需要在内部使用特定的格式、技术或标准，这会给实现技术的选择带来限制。
6. 将作为服务公开的系统实现功能支持所需的技术或开放标准（比如 SOAP、JMS或 XML）吗？
   • 如果不支持，ESB 基础架构或适配器将需要在所需的开放标准和服务提供者支持的格式之间进行转换的功能。
7. 在需要访问遗留系统的情况下，通过使用更新的基于 XML 的技术，可以直接支持（例如 CICS SOAP 支持）遗留系统的可用性吗？是否需要单独的适配器？遗留平台是否支持 XML 处理？如果支持，这种处理是否可以灵活地使用平台功能？
   • 如果因为这其中的任何原因而导致所需的 SOAP 或 XML 功能对遗留平台不可用，则需要在适配器（比如s J2C Connector Architecture (JCA) 或 WebSphere Business Integration Adaptors）、集成层或 ESB 基础架构中使用适当的转换功能。
8. 如果 EAI 技术已经可用，它是否使用适当的功能或接口粒度将服务作为消息流实现？它支持哪些连接性协议（例如 JCA、SOAP、WebSphere MQ 以及 Java 远程方法调用（Java Remote Method Invocation））？
   • 如果现有消息流不提供所需要的服务，则需要另外的流程来执行转换。如果 EAI 技术不直接支持所需的标准，就需要添加一个网关组件。
9. 应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护措施？
   • 这种缓冲通常是 ESB 基础架构的一个角色，并且定义它所需要一些功能。如果特定的服务提供者系统（例如遗留事务系统（legacy transactional systems））需要额外的保护，则可以使用专用集成层。
10. 应该实现多少服务？实现的什么方面应该在这些服务中保持一致？如何实施一致性（可能在多个平台上和多个应用程序中）？
    • 如果只需要非常少的服务，简单的点到点（point-to-point）集成模型可能比较适合。然而，如果需要更多的服务或者过一段时间以后可能还是如此，则添加控制点（比如由 ESB 提供的）就变得愈加有益。
11. 服务交互包含在组织内部，还是有一些交互在组织外部？
    • 这常常是不同于在单个组织中实现的 ESB 基础架构的一种情况，因为对安全和服务路由的需求可能与外部可用的服务不同。
12. 是否需要服务编排？服务编排是否涉及短期（short-lived）或长期（long-lived）（换句话说就是有状态的）流程，还是两者都涉及？它们是否包含人工活动？
    • 在这些需求构成业务功能的情况下，应该在与 ESB 分离的 Service Choreographer 组件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。
13. 基础架构应该支持什么样的服务级需求（例如，服务响应时间、吞吐量、可用性等等）？随着时间的推移，需要如何对其进行扩展？
    • 一些候选的 ESB 实现技术相对较新，并且可能仅仅在有限的服务级进行过测试。同样，由于相关的开放标准不是最近制订就是正在兴起的，所以在更多的既定产品和技术中对它们的支持也是新出现的。
    • 在可以预见的未来，关键的体系结构决策将专注于特定开放标准优点的平衡，针对服务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持它们的产品是相对成熟的（例如 XML、SOAP等等），有些（例如 Web 服务安全（WS-Security））比较新，还有一些（例如 Web 服务事务）是正在兴起的。
    • 标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了 ESB 与 SOA 体系结构中适应标准的、专有的或自定义技术的混合方法。
14. 是否需要点到点（point-to-point）或端到端（end-to-end）安全模型（例如，ESB 是否可以简单的对服务请求授权，还是需要将请求者的身份或其他凭证传递给服务提供者）？是否需要使用应用程序或遗留安全系统来集成服务安全模型？
    • 如果点到点安全性是可接受的，则许多现有解决方案（例如 SSL 、对数据库访问的 J2EE 安全性、适配器安全模型等等）就能够得到应用。如果需要端到端安全性，则 Web 服务安全标准就成为可能，提供所有相关的系统来支持它。换句话说，您可以使用带有客户端消息头的客户端模型，或者传送像应用程序数据这样的安全信息。

    结束语
   
    本文确定了一些 ESB 实现中最常见的场景，以及对相应的解决方案直接产生影响的问题。虽然没有完全涵盖所有的隐藏问题，但这些是其中最常遇到的。

    我们概述了从两个系统的基本集成到实现支持高质量服务和 Web 服务标准的 SOA 体系结构的常见场景。并描述了需要重视的十四个不同的问题：

• 现有数据接口
• 业务数据模型
• 开放标准的使用
• 对基本或高级通信协议的支持
• 通过现有系统对数据传递格式的修改
• 通过新技术公开现有服务
• 对遗留系统的访问
• 现有 EAI 技术
• 需要的保护措施
• 需要提供多少服务和需要的一致性程度
• 公司内部以及与其他公司之间的互操作
• 对服务编排的需求
• 服务级需求的基础架构级支持
• 点到点（point-to-point）或端到端（end-to-end）安全模型的使用

    理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第 3 部分，我将讨论本文中提到的实际解决方案。如下：

• 基本适配器
• 服务网关
• Web services Compliant Broker
• Service Choreographer
• 用于 SOA 的 EAI 体系结构
• 完整的 SOA 体系结构

    最后，我将讨论组织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能够指导您开发自己的 ESB 路线的一些问题。