面向服务的体系结构中企业服务.docx
理解面向服务的体系结构中企业服务总线场景和解决方案第 1 部分企业服务总线中的工作角色 Rick Robinson （rick_robinson） IT 架构师, IBM2004 年 7 月 本文确定了一组最低功能，可以满足企业服务总线（Enterprise Service Bus，ESB）与面向服务的体系结构（service-oriented architecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。 引言最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件（请参见参考资料）。然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能。本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA 实现的共同起点。而解决方案模式又为选择适当的实现技术提供了指南。随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法。ESB 在 SOA 内的工作角色虽然我不打算深入讨论 SOA 的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的：· 利用显式的与实现无关的接口来定义服务。 · 利用强调位置透明性和可互操作性的通信协议。 · 封装可重用业务功能的服务的定义。 图 1 说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。图 1: SOA 的原则为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的 ESB 功能模型部分中所述。ESB 结构ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB 和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。图 2 展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。图 2: 分布式 ESB 基础架构的集中控制我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA 原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图 3 展示的 SOA 说明了这些组件之间的关系。图 3: SOA 中的 ESB 角色ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。ESB 的功能模型表 1 对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB 实现所需的最低功能将在下面支持 SOA 的最低功能的 ESB 实现部分中进行探讨。表 1：在现有的文献中定义的 ESB 功能通信服务交互· 路由 · 寻址 · 通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS） · 发布/订阅 · 响应/请求 · Fire-and-Forget，事件 · 同步和异步消息传递 · 服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL） · 支持替代服务实现 · 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型） · 服务目录和发现 集成服务质量· 数据库 · 服务聚合 · 遗留系统和应用程序适配器 · EAI 中间件的连接性 · 服务映射 · 协议转换 · 应用程序服务器环境（例如 J2EE 和 .NET） · 服务调用的语言接口（例如 Java 和 C/C+/C#） · 事务（原子事务、补偿、Web 服务事务（WS-Transaction） · 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持） 安全性服务级别· 身份验证 · 授权 · 不可抵赖性 · 机密性 · 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security） · 性能 · 吞吐量 · 可用性 · 其他可以构成契约或协定的持久评估方法 消息处理管理和自治· 编码的逻辑 · 基于内容的逻辑 · 消息和数据转换 · 有效性 · 中介 · 对象标识映射 · 数据压缩 · 服务预置和注册 · 记录、测量和监控 · 发现 · 系统管理和管理工具的集成 · 自监控和自管理 建模基础架构智能· 对象建模 · 通用业务对象建模 · 数据格式库 · B2B 集成的公共与私有模型 · 开发和部署工具 · 业务规则 · 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy） · 模式识别 上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论 ESB 为支持 SOA 所需的最低功能由什么构成。支持 SOA 的最低功能的 ESB 实现如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理： · ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。 · SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。 · ESB 可以作为分布式的异构基础架构进行实现。 · ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。 表 2 展示了根据这些原则定义的最低 ESB 功能表 2: 最低的 ESB 功能通信集成· 提供位置透明性的路由和寻址服务 · 控制服务寻址和命名的管理功能 · 至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等） · 支持至少一种可以广泛使用的传输协议 · 支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等 服务交互一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：· URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。 · SOAP/HTTP 支持请求-响应（Request-Response）通信规范。 · HTTP 传输协议被广泛地使用。 · SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。 然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能： · 目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。 · 虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。 当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：· 服务质量和服务级别功能。 · 高级 SOA 概念，例如服务编排、目录、转换等等。 · 按需操作环境需求，比如管理与自治功能以及基础架构智能功能。 · 跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。 影响 ESB 的安全问题我不想在这里直接提出安全需求，不过它们对选择 ESB 的实现技术非常重要。例如，如果服务请求不需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安全级别，则评估什么形式的安全是可以接受的就非常重要。例如：1. 是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接字层（Secure Socket Layer，SSL）互相验证，或者是否在使用 HTTPS 协议？ 2. 是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？ 3. 是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID 和密码的基本 HTTP 身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？ 4. 是否需要遵守行业安全标准，例如 Kerberos 或 WS-Security？ 虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如 Web 服务安全性（WS-Security）功能。然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。因此，任何 ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。 结束语在本文中，我讨论了大多数通用的 SOA 原则，以及它们与 Web 服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。这些功能都是通过 ESB 实现的。ESB 在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能需要业务服务目录。Business Service Choreographer 从 ESB 调用服务，然后通过 ESB 把这些流程作为新的服务公开。ESB 的许多功能包括提供： · 通信 · 服务交互 · 集成 · 质量服务 · 安全 · 服务级别 · 消息处理 · 管理及自治服务 · 建模 · 基础架构智能 从这些不同的功能中，我确定了建立 ESB 所需的最低功能，包括通信、集成和服务交互。 在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。第 2 部分驱动体系结构的 ESB 场景和问题Rick Robinson （rick_robinson） IT Architect, IBM2004 年 7 月 在关于企业服务总线（Enterprise Service Bus，ESB）的这个系列的第二部分中，作者描述和分析了实现 ESB 和其他面向服务的体系结构（SOA）的解决方案的一些常见场景。 这个系列的第 1 篇文章描述了企业服务总线（Enterprise Service Bus，ESB）的基本概念和工作角色。本文侧重于描述为支持面向服务的体系结构（SOA）而进行的 ESB 开发的场景和问题。您的组织的 SOA 和 ESB 可能需要应用到一个或多个这样的场景。ESB 场景及分析SOA 中的 ESB 场景部分描述了许多 SOA 和 ESB 实现的起点。每个场景都指出驱动体系结构和设计决策的问题，而这些决策会影响解决方案模式的选择（将在这个系列的第 3 部分中进行介绍）。在驱动 ESB 体系结构和设计决策的问题部分中，您可以阅读关于这些问题的详细描述。这些解决方案模式代表着从服务技术的基本使用，到简单的 ESB 实现，再到复杂的 SOA 体系结构的发展过程。 这些 ESB 场景的目的并不在于展示组织对 SOA 或 ESB 的全部需求。例如，虽然某个场景（如两个系统的基本集成）可能看起来很好地匹配了特定的当前需求，但是随着时间的推移，这种需求可能发展成更复杂的需求（如支持一个或多个应用程序实现更广泛的连接性场景。另外，还可能有许多对 SOA 或 ESB 基础架构的单独需求会出现这样的情况，就其个别而言符合简单场景，但集中在一起则表现得比较复杂。我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景（如实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构）可能是比较适合的。另外，还可以将个别的情形单独看作是简单场景，但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。SOA 中的 ESB 场景下面的几个部分描述了这些场景的特征：· 两个系统的基本集成 · 支持一个或多个应用程序实现更广泛的连接性 · 支持遗留系统实现更广泛的连接性 · 支持企业应用程序集成（EAI）体系结构实现更广泛的连接性 · 实现组织之间服务或系统的受控集成 · 通过编排服务使流程自动化 · 实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构 两个系统的基本集成 场景企业需要提供用不同的技术（如 J2EE、.NET、CICS 等等）实现的两个系统之间的集成。Web 服务 SOAP 标准或消息传递中间件可能是候选的集成技术。这个场景的一个重要的问题是，将来是否会出现需要集成其他系统的情况。一开始就使用可扩展解决方案可能会对未来的需要提供支持；但是必须在为构建这样的解决方案而付出的额外工作与解决简单的问题的最初需要之间保持平衡。 最相关的问题相关的解决方案模式（请参见下一篇文章）1,3,4,6,10,13· 使用包装器或适配器来实现基本集成请参见基本适配器。 · 或者，想要在将来进行扩展，有以下两种方案： o 添加控制服务网关。 o 或者实现一个复杂的基础架构比如 Web services Compliant Broker或EAI Infrastructure for SOA。 支持一个或多个应用程序实现更广泛的连接性 场景现有的已封装或自定义开发的应用程序（例如客户关系管理（Customer Relationship Management，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）可能是用 J2EE 平台或其他应用程序服务器环境实现的，它们提供的可用功能超出了应用程序本身。以服务的形式公开这些功能的价值在于，既支持应用程序彼此之间的互操作，也提供对新的通道或客户端的访问。使用可互操作或开放的标准通信和服务协议看来是今后发展的最佳途径。 最相关的问题相关的解决方案模式（请参见下一篇文章）1、2、3、4、6、8、9、10、11、12、13、14· 使用包装器或适配器来实现基本集成请参见基本适配器。 · 添加控制服务网关。 · 或者实现一个复杂的基础架构比如 Web services Compliant Broker或EAI Infrastructure for SOA。 · 如果还需要流程编排（Process Choreography），就实现Service Choreographer或者Full SOA Infrastructure。 支持遗留系统实现更广泛的连接性 场景组织对遗留技术（比如 CICS、IMS 等等）进行了大量的投资，以支持为他们提供核心业务事务和数据访问的应用程序。其重要价值在于提供互操作性或开放标准、以及对这些事务进行基于服务的访问（例如，查询帐户余额的事务、创建订单、日程安排或交付跟踪、查询库存级别等等）。 最相关的问题相关的解决方案模式（请参见下一篇文章）1,2,3,4,7,8,9,10,11,13,14· 使用包装器或适配器来实现基本集成请参见基本适配器。 · 或者，想要在将来进行扩展，有以下两种方案： o 添加控制服务网关。 o 或者实现一个复杂的基础架构比如 Web services Compliant Broker或EAI Infrastructure for SOA。 支持企业应用程序集成（EAI）基础架构实现更广泛的连接性 场景需要对现有的 EAI 基础架构（如 IBM WebSphere Business Integration）进行扩展，以对其进行基于可互操作协议或开放标准的访问。虽然根据 XML 业务数据并通过高度可互操作协议（如 HTTP 或 WebSphere MQ）公开服务接口可以在某些场景中提供适当的互操作性级别，但是如果对现有的集成范围的自定义开发或专有扩展都不是可接受的，则可能需要支持 WSDL 和 SOAP Web 标准。 最相关的问题相关的解决方案模式（请参见下一篇文章）3、4、5、8、9、11、13、14· 使用开放数据格式及 EAI Infrastructure for SOA 来扩展 EAI 基础架构。 · 添加控制服务网关。 · 或者对带有 Web services Compliant Broker 的基础架构增加开放标准支持。 实现组织之间服务或系统的受控集成 场景组织希望使其客户、供应商或其他合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供的功能。控制的重点是需要提供从外部各方到这些应用程序的安全且易管理的访问。因为组织不能直接控制其合作伙伴所使用的技术，因此最好使用开放标准。此场景既可以应用于分散的组织之间，也可以应用于大型分布式组织的各个单位之间。 最相关的问题相关的解决方案模式（参见下一篇文章）1、2、3、4、6、8、9、10、11、13、14· 添加服务网关。 · 或者如果需要更多的复杂功能，就实现 Web Services Compliant Broker。 通过编排服务使流程自动化 场景（注意：此场景可以看作是支持一个或多个应用程序实现更广泛的连接性场景的发展。它不被当作一个 ESB 场景，因为服务编排通常是与 ESB 分开实现的，正如本系列的第一篇文章所述。然而，我之所以把它包括在这里，是因为此场景往往驱动对 ESB 和服务编排组件的需求。） 现有的已封装（例如，客户关系管理（Customer Relationship Management，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）或自定义开发的应用程序可能是在 J2EE 平台或其他应用程序服务环境中实现的，它们提供的可用功能超出了应用程序本身。可以使用可互操作或开放通信和服务协议将这些功能作为服务公开，这样应用程序就可以交互。可以在某些层次上组合这些交互以构成业务流程。应该使用适当的建模和流程执行技术（可能遵守适当的开放标准）来对这些流程进行显式建模。 最相关的问题相关的解决方案模式（请参见下一篇文章）1、2、3、4、6、10、11、12、13、14· 如果服务的直接连接是可能的，则实现 Service Choreographer。 · 如果需要更复杂的集成或控制，则实现 Full SOA Infrastructure。 实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构 场景此场景是由前面的组成的。它代表了对由多个应用程序、遗留系统等等提供的服务进行普遍的内部或外部访问的需要。需要各种安全、聚合、转换、路由以及服务编排功能。IT 组织以响应所支持的业务不断增加的需求，从而使得能够在业务系统之间进行更普遍且更灵活的集成。 最相关的问题相关的解决方案模式（请参见下一篇文章）全部· 实现 Full SOA Infrastructure。 驱动 ESB 体系结构和设计决策的问题为了确定用于 ESB 的合适解决方案模式和实现技术，需要对特定的 ESB 功能需求进行详细的分析。下面的问题旨在帮助进行这一过程，而前面的部分指出了与每个场景相关的特定问题。1. 现有功能及其数据接口是否与您想要提供的服务相匹配？您是否能够修改或聚合应用程序？ o 如果不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供，或者不得不由服务客户端来完成。 2. 服务是否可以以一些通用业务数据模型的形式公开？如果可以，则实现这些服务的系统是否已经支持该模型？或者说可以使它们这样做？ o 如果服务不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供。 3. 是否需要开放标准？或者是否可以通过 EAI 中间件来实现适当的互操作性？如果需要开放标准的话，则哪些开放标准是适合的？ o 虽然使用开放标准是实现互操作性的一种途径，但专有的 EAI 中间件也具有高度的互操作性，并且往往要成熟得多。另外，许多组织还拥有广泛的现有基础架构，在一些场景中，它们可能会使得开放标准的作用几近于无。 o 在需要开放标准的场景中，Web 服务也许是这些情况下最明显的选择。不过，您也可以应用 Java Messaging Service (JMS)、JDBC、基本 XML 或者一些其他的技术（比如 EDI 或业界通用的 XML 格式。 o 在实践中，不能总是假定相同标准的不同实现之间具有互操作性，特别是对于近来出现或刚刚兴起的标准。对于 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）等等）？ o 对支持更复杂标准的需求将对实现技术的选择加以更严格的约束，并且可能意味着使用还不成熟的技术。 5. 当果考虑更改现有的基础架构使用的消息格式和协议（包括可能采用开放标准）时，需要在整个现有的基础架构中进行这些更改吗？或者很快就要应用新的消息格式和协议吗？如果正在使用或考虑使用 EAI 技术，该技术是否有自己的内部格式？或者它能够将开放标准处理为内部格式吗？ o 开放标准的任何应用都是受扩展访问的需求驱动的，因此它们对现有基础架构的接口的可用性比在内部使用的这样的标准更重要。 o 如果需要在内部使用特定的格式、技术或标准，这会给实现技术的选择带来限制。 6. 将作为服务公开的系统实现功能支持所需的技术或开放标准（比如 SOAP、JMS或 XML）吗？ o 如果不支持，ESB 基础架构或适配器将需要在所需的开放标准和服务提供者支持的格式之间进行转换的功能。 7. 在需要访问遗留系统的情况下，通过使用更新的基于 XML 的技术，可以直接支持（例如 CICS SOAP 支持）遗留系统的可用性吗？是否需要单独的适配器？遗留平台是否支持 XML 处理？如果支持，这种处理是否可以灵活地使用平台功能？ o 如果因为这其中的任何原因而导致所需的 SOAP 或 XML 功能对遗留平台不可用，则需要在适配器（比如s J2C Connector Architecture (JCA) 或 WebSphere Business Integration Adaptors）、集成层或 ESB 基础架构中使用适当的转换功能。 8. 如果 EAI 技术已经可用，它是否使用适当的功能或接口粒度将服务作为消息流实现？它支持哪些连接性协议（例如 JCA、SOAP、WebSphere MQ 以及 Java 远程方法调用（Java Remote Method Invocation）？ o 如果现有消息流不提供所需要的服务，则需要另外的流程来执行转换。如果 EAI 技术不直接支持所需的标准，就需要添加一个网关组件。 9. 应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护措施？ o 这种缓冲通常是 ESB 基础架构的一个角色，并且定义它所需要一些功能。如果特定的服务提供者系统（例如遗留事务系统（legacy transactional systems）需要额外的保护，则可以使用专用集成层。 10. 应该实现多少服务？实现的什么方面应该在这些服务中保持一致？如何实施一致性（可能在多个平台上和多个应用程序中）？ o 如果只需要非常少的服务，简单的点到点（point-to-point）集成模型可能比较适合。然而，如果需要更多的服务或者过一段时间以后可能还是如此，则添加控制点（比如由 ESB 提供的）就变得愈加有益。 11. 服务交互包含在组织内部，还是有一些交互在组织外部？ o 这常常是不同于在单个组织中实现的 ESB 基础架构的一种情况，因为对安全和服务路由的需求可能与外部可用的服务不同。 12. 是否需要服务编排？服务编排是否涉及短期（short-lived）或长期（long-lived）（换句话说就是有状态的）流程，还是两者都涉及？它们是否包含人工活动？ o 在这些需求构成业务功能的情况下，应该在与 ESB 分离的 Service Choreographer 组件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。 13. 基础架构应该支持什么样的服务级需求（例如，服务响应时间、吞吐量、可用性等等）？随着时间的推移，需要如何对其进行扩展？ o 一些候选的 ESB 实现技术相对较新，并且可能仅仅在有限的服务级进行过测试。同样，由于相关的开放标准不是最近制订就是正在兴起的，所以在更多的既定产品和技术中对它们的支持也是新出现的。 o 在可以预见的未来，关键的体系结构决策将专注于特定开放标准优点的平衡，针对服务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持它们的产品是相对成熟的（例如 XML、SOAP等等），有些（例如 Web 服务安全（WS-Security）比较新，还有一些（例如 Web 服务事务）是正在兴起的。 o 标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了 ESB 与 SOA 体系结构中适应标准的、专有的或自定义技术的混合方法。 14. 是否需要点到点（point-to-point）或端到端（end-to-end）安全模型（例如，ESB 是否可以简单的对服务请求授权，还是需要将请求者的身份或其他凭证传递给服务提供者）？是否需要使用应用程序或遗留安全系统来集成服务安全模型？ o 如果点到点安全性是可接受的，则许多现有解决方案（例如 SSL 、对数据库访问的 J2EE 安全性、适配器安全模型等等）就能够得到应用。如果需要端到端安全性，则 Web 服务安全标准就成为可能，提供所有相关的系统来支持它。换句话说，您可以使用带有客户端消息头的客户端模型，或者传送像应用程序数据这样的安全信息。 结束语本文确定了一些 ESB 实现中最常见的场景，以及对相应的解决方案直接产生影响的问题。虽然没有完全涵盖所有的隐藏问题，但这些是其中最常遇到的。我们概述了从两个系统的基本集成到实现支持高质量服务和 Web 服务标准的 SOA 体系结构的常见场景。并描述了需要重视的十四个不同的问题： · 现有数据接口 · 业务数据模型 · 开放标准的使用 · 对基本或高级通信协议的支持 · 通过现有系统对数据传递格式的修改 · 通过新技术公开现有服务 · 对遗留系统的访问 · 现有 EAI 技术 · 需要的保护措施 · 需要提供多少服务和需要的一致性程度 · 公司内部以及与其他公司之间的互操作 · 对服务编排的需求 · 服务级需求的基础架构级支持 · 点到点（point-to-point）或端到端（end-to-end）安全模型的使用 理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第 3 部分，我将讨论本文中提到的实际解决方案。如下：· 基本适配器 · 服务网关 · Web services Compliant Broker · Service Choreographer · 用于 SOA 的 EAI 体系结构 · 完整的 SOA 体系结构 最后，我将讨论组织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能够指导您开发自己的 ESB 路线的一些问题。理解面向服务的体系结构中企业服务总线场景和解决方案，第 3 部分ESB 场景的解决方案级别: 初级Rick Robinson （rick_robinson） IT Architect, IBM2004 年 7 月 这个系列文章的第 3 部分介绍了实现企业服务总线（Enterprise Service Bus，ESB）的场景和解决方案，在此作者分析了第 2 部分概述的多个场景可能的解决方案。在第 1 部分中说明的总线工作角色提供了这些场景的基础。 下面继续这个系列来构建面向服务体系结构（Service-Oriented A
