理解面向服务的体系结构中企业服务总线场景和解决方案样本.doc

了解面向服务体系结构中企业服务总线场景和处理方案第 1 部分企业服务总线中工作角色 Rick Robinson （） IT 架构师, IBM 年 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 （） IT Architect, IBM 年 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 （） IT Architect, IBM 年 7 月 这个系列文章第 3 部分介绍了实现企业服务总线（Enterprise Service Bus，ESB）场景和处理方案，在此作者分析了第 2 部分概述多个场景可能处理方案。在第 1 部分中说明总线工作角色提供了这些场景基础。 下面继续这个系列来构建面向服务体系结构（Service-Oriented Architecture，SOA）企业服务总线，现在我们来看一看第 2 部分（请参阅参考资料）中所描述场景多个显而易见处理方案模式。 以下每个部分全部描述了一个 ESB 实现方法处理方案模式，除了基础适配器（Basic Adaptors）模式以外，其它全部是简单点到点（P2P）处理方案。每个模式全部提出了不一样使用现行技术实现选择，同时也做出了正反两方面和移植方面考虑。 请注意每个处理方案模式图示，它认为服务用户端和提供服务系统是分离。当然，在很多情况下，相同系统或应用程序既能够是服务用户端也能够是服务提供者。图示并非是要排除系统作为单独用户端和提供者可能性，而是认可了相同系统在不一样互操作中能够有两种不一样工作角色。在决定系统是作为用户端角色来选择、确定和调用服务，还是作为提供者角色来接收、处理和响应服务请求时，这个区分通常很关键。 本部分处理方案模式有： 基础适配器（Basic Adaptors） 服务网关 Web 服务兼容代理（Web Service-compliant Broker） 面向服务体系结构企业应用集成基础架构（EAI Infrastructure for SOA） 服务编排（Service Choreographer） 完整面向服务体系结构基础架构（Full SOA Infrastructure） 基础适配器处理方案模式这种处理方案经过封装器或适配器技术来实现简单点到点（P2P）服务集成，而不是真正 E