理解SOA体系结构中ESB场景和解决方案

1、引言最新的tt集成是使用web服务技术实现面向服务的体系结构(soa),有 许多优秀的文章讲述了该技术的好处和相关的实践。最近，企业服务总线(enterprise service bus, esb)的概念被表述为soa基础架构的关键组件。 然而，冇必要阐明esb究竟是一个产品、技术、标准，述是别的什么。特别是, 当前是否可以构建esb?如果这样，该如何构建？本文将esb描述为ft!中间件技术实现并支持soa的一组基础架构功能。 esb支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务 级别和可管理性。为了达到此目的，需要将多种功能集屮起来并加以分类。然而, 并不是esb能够传递

2、值的每一种情形都需要所有的功能。木文确定了一组最低功能，可以满足esb与soa的原则保持一致的基本需 要。通过确定这些最低功能，您可以确定利用何种现冇技术來实现支持soa的 esbo通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适 合这种情形的实现技术。随着esb解决方案的发展和成熟，它所需要的功能也在不断地发展。同样, 可见的esb产品的可用性和功能也日趋完善。因此，在木系列的最后一篇文章 中，我将考虑s0a和esb的发展路线，以指导esb功能和技术的最初应用， 并且阐述如何选择循序渐进的方法。esb在s0a内的工作角色虽然我不打算深入讨论s0a的定义，但是在这里概括一下大部

3、分对s0a的 描述所适用的原则是很有用的：1. 利用显式的与实现无关的接口來定义服务。接口无关性2. 利用强调位置透明性和可互操作性的通信协议。通信透明性3. 封装可重用业务功能的服务的定义。重用图1说明了这些原则。注意，虽然web服务技术非常符合这些原则，但它并不是唯-符合这些原则的技术。&ystcm 1liter问 orfe血 p5«e6®esgmshared process andinterface definitiomsinterface code exposing wellencapsulated servicespfolaaols wbhtamlkn t

4、fansfrarwcontractmtefoi?efahe (moloaols wflh6d 询 bn fcansfrariicyinterface code exposing wellencapsulated servicesar§ pmeesee图1: soa的原则为了实现soa,应用程序和基础架构都必须支持soa原则。启用soa应用 程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于 现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将 服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的 客户端的情况下由另一个服务实现替

5、代原有的服务实现也是至关重耍的。这不仅 需要根据soa原则指定服务接口，而且需要基础架构允许客户端代码以独立于 所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 esb的许多功能中的一部分。esb支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架 构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实 体。esb为soa提供与企业需要保持一致的基础架构，从而提供合适的服务级 别和可管理性、以及异构环境中的操作。木文剩余部分将讨论esb在soa屮的角色，包括它提供的除了基木的路由 和传输以外的功能，如下面的esb功能模型部分中所述。esb结构esb有

6、时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如 消息代理技术一般被描述为中心辐射型(hub-mid-spoke)。然而，这并不是真 正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。esb和屮 心辐射型(hub-and-spoke)解决方案都集中控制配置，比如服务交互的路由、 服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也 可能采用更复杂的分布式方式进行部署。图2展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式冇不同的约束冇些 可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的 可能更适合于部署在本地群集中，以支

7、持高可用性和可伸缩性。使物理分布需求 与候选技术的功能相匹配是esb设计的一个重要方面。另外的一种能力也是非 常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的 系统或扩展基础架构的物理范围。interface oradaptordtsfd&uted nraslrctur&run timeruntimeengineinterface oradaptorruntimeengine<3distribution | ；interface oradaptoradministration and conlrolclerlclleflcleiit%interfac

8、e or adaptorinterface or adaptor interface or adaptor 图2:分布式esb基础架构的集中控制1.我还应该定位在soa基础架构屮esb与其他组件z间的关系，特 另 u 是与 service direc to ry> business service choreography 动 作设计、以及 business-to-business (b2b) gateway 这些组件之 间的关系。由于上述soa原则对这些组件并没有严格的要求，所以 我们可以将它们视为可选组件图3展示的s0a说明了这些组件之 间的关系。for 湘tvbzfi砒ued图3:

9、 soa中的esb角色esb需要某种形式的服务路由目录(service routing路由directory) 来路由服务请求。然而,soa可能还有单独的业务服务目录(business service directory)，其最基本的形式可能是设计时服务目录，用于在组织的整个开发 活动屮实现服务的重用。web服务远景在业务服务口录和服务路由口录的角色屮 都放置了一个uddi目录，因而使得可以动态发现和调用服务。这样的目录可以 视为esb的一部分；然而，在这样的解决方案变得普遍z前，业务服务目录可 能与esb是分离的。business service choreographer的作用是通过若干业

10、务服务来组合业务 流程；因此，它将通过esb调用服务，然后再次通过esb将业务流程公开为客 户端可用的-其他服务。然而，business service choreographer在编排业务流 程和服务小所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 esb分离的技术。最后，b2b gateway组件的作用是使两个或多个组织的服务在受控且安全的 方式下对彼此可用。这有助于查看这些连接到esb的组件，但它们并不是esb 的一部分。虽然有一些网关技术可以提供适合于实现b2b gateway组件和esb 的功能，但是b2b gateway组件的用途是将其与esb分离。事实上,这种用途 可能

11、需要附加的功能（如合作伙伴关系管理），这些功能不是esb的一部分， 并且不一定受到esb技术的支持。esb的功能模型表1对现有文献小确定的一些esb功能进行了总结和分类。虽然有一些功 能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作 环境转变的重要步骤。重耍的是认识到，当前的人多数场景只需耍部分类别中的 部分功能。esb实现所需的最低功能将在下面支持soa的最低功能的esb实现 部分中进行探讨。if信巌务交互1.略由1服务接口定义（例如，web服务羟述语言2.寻址(web services description language »3.通信技术、协议和标准（例

12、如wsdl)ibm® websphere® mq. http2支持替代服务实现和 https )3通信和集成所需的服务消息传递模型（例如4.发布/订阅soap或企业应用程序集成（eai）中间件模5.响应/谙求型）6.fire-andforget / 事件4服务目录和发现7.同步和异步消息传递集成1数据库1.爭务（原子爭务、补偿、web服务爭务（ws-2.服务聚合transaction )3.遗留系蜒和应用程序适配器2.各种确定的传递范例（例如web服务可靠消4eai中间件的连接性息传递（ws-rji“x壯乜隔ing ）或对eai5.服务映射中间件的支持）6.协议转换7应用程

13、序服务器环境（例如j2ee 和 net )8.服务调用的语言接口（例如java 和 c/c+/c#)安全性巌务馥别1.身份验证1.性能2.授权2.吞吐量3.不可抵赖性3.可用性4.机密性4.其他可以构成契约或协定的持久评估方法5.安全标准（例如kerberos和web服务安全性（ws-security)消息处理管理和自治1編码的逻辑1服务预置和注册2基于内容的逻辑2记录、测星和监控3.消息和数据转换3.发现4.有效性4.系统管理和管理工具的集成5.中介5自监控和自管理6.对象标识映射7.数据压缩建複基础架构智盅1.对象建複1.业务规则2.通用业务对象建複2.策路驱动的行为,特别是对于服务级别、

14、服务3.数据格式库功能的安全和质量（例如web服务策略（ws-4.b2b集成的公共与私有複型policy)5.开发和部署工具3.模式识别表1：在现有的文献中定义的esb功能上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现esb可能会使它们的性能、可伸缩性和可靠性这 些特性显著不同，同吋esb功能和所支持的开放标准也会有所不同。由于这些 原因，再加上最近制订和正在兴起的一些相关标准，当今实现esb的许多关键 决策都涉及到成熟的专冇技术和不成熟的开放标准z间的权衡。在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们 将集中讨论采用或实现r

15、sb的不同方法之间的驱动策略。特别是在下一部分， 我们将讨论esb为支持soa所需的最低功能由什么构成。支持soa的最低功能的esb实现如果在前而确定的功能屮只冇一部分和大多数soa场景相关，我们可能会 问：实现esb所需的一组最低功能由什么构成？为此,考虑最被普遍认同的esb 定义的原理：1. esb是一种逻辑体系结构组件，它提供与soa的原则保持一致的集成基 础架构。2.s0a原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的 通信协议、相对粗粒度和封装叮重用功能的服务定义。3. esb可以作为分布式的异构基础架构进行实现。4. esb提供了管理服务基础架构的方法和在分布式异构环

16、境屮进行操作的 功能。表2展示了根据这些原则定义的最低esb功能通信集成1. 提供位置透明性的賂由和寻址服务2. 控制服务寻址和命名的管理功能3. 至少一种形式的消息倍递范型(例如，谙求/响应.发布/订阅 等等)4. 支持至少一种可以广泛使用的倍输协议1 支持服务提供的多种集成方式比如java2连接器、壯b服务.异步通信、适配器服务交互一个开放且与实现无关的服务消息倍递与接口模型，它应该将应用程序代码从賂由服务和传输 协议中分离出来，并允许替代服务的实现。表2:最低的esb功能请注意这些最低功能并不需要使用特别的技术，比如eai中间件、web服 务、j2ee或xmlo这些技术的使用非常接近也非

17、常符合需求，但是不必强制要 求使用它们。相反，最低功能几乎只需简单地使用s0ap/http和wsdl就可以 实现(当然不是所有的情况都这样):1. url寻址和现有的http和dns基础架构提供了一个具有路由服务和位 置透明性的“总线(bus) ”。2. s0ap/http 支持请求-响应(request-response)通信规范。3. http传输协议被广泛地使用。4. soap和wsdl是开放、与实现无关的服务通信和连接模型。然而，这些s0ap/http和wsdl的基本应用只是点到点(point-to-point) 的集成，并不能实现一些esb需要的关键功能：1. 耳前还没冇用于控制服务

18、寻址和命名的管理功能。服务名称通过每个适配 器单-独进行控制的，服务路由控制则分散在由服务客户端调用的地址、http基 础架构和分配给适配器的服务名称之间。2. 虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得 简单；服务请求者代码(也口j能是开发工具生成的)通常通过特定地址的特定协 议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的 服务实现，就需要修改应用程序代码并重新部署这些代码。当然，在许多其至是大多数情形屮往往需要其他的功能，并且这种需要 变得越來越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更 复杂高级的技术的使用：1服务质量和服务

19、级别功能。2高级soa概念，例如服务编排、目录、转换等等。3. 按需操作环境需求，比如管理与自治功能以及基础架构智能功能。4. 跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异 步操作。影响esb的安全问题我不想在这里直接提出安全需求，不过它们对选择esb的实现技术非常重 要。例如，如果服务请求不需要捉供身份验证或授权，实现技术的选择就可以非 常的广泛。更有可能的情况是，如果需耍一些安全级别，则评估什么形式的安全 是口j以接受的就非常重要。例如：1 是否可以接受迪值基础架构中的安全性，例如，是否在eai中间件服务 益之间使用安全套接字层(secure socket layer, ssl)互相验证，或者是否在 使用https协议？2. 是否可以接受在参与系统z间单独的点到点(point-to-point)安全性， 或者是否需要端到端(end-to-end)模型？例如，是否冇必要通过类似于代理的 屮间件系统来把客户端身份传递到服务实现的最终提供者？3是否可以接受应用层中的安全性，例如，客户端代码是否能