HYPERLINK""了解面向服务体系结构中企业服务总线场景和处理方案第1部分企业服务总线中工作角色HYPERLINK""\l"author1"RickRobinson（HYPERLINK"mailto:"）IT架构师,IBM年7月本文确定了一组最低功效，能够满足企业服务总线（EnterpriseServiceBus，ESB）和面向服务体系结构（service-orientedarchitecture，SOA）标准保持一致基础需要。经过确定这些最低功效，您能够确定利用何种现有技术来实现支持SOAESB。经过考虑特定情形下需求怎样确定对额外功效需要，您能够选择最适合这种情形实现技术。引言最新IT集成是使用Web服务技术实现面向服务体系结构（SOA），有很多优异文章讲述了该技术好处和相关实践（请参见HYPERLINK""\l"resources"参考资料）。最近，企业服务总线（EnterpriseServiceBus，ESB）概念被表述为SOA基础架构关键组件（请参见HYPERLINK""\l"resources"参考资料）。然而，有必需说明ESB到底是一个产品、技术、标准，还是别什么。尤其是，目前是否能够构建ESB？假如这么，该怎样构建？本文将ESB描述为由中间件技术实现并支持SOA一组基础架构功效。ESB支持异构环境中服务、消息，和基于事件交互，而且含有合适服务等级和可管理性。为了达成此目标，需要将多个功效集中起来并加以分类。然而，并不是ESB能够传输值每一个情形全部需要全部功效。本文确定了一组最低功效，能够满足ESB和SOA标准保持一致基础需要。经过确定这些最低功效，您能够确定利用何种现有技术来实现支持SOAESB。经过考虑特定情形下需求怎样确定对额外功效需要，您能够选择最适合这种情形实现技术。在接下来文章中，我将在SOA中定义一组ESB场景，以定义ESB或SOA实现共同起点。而处理方案模式又为选择合适实现技术提供了指南。伴随ESB处理方案发展和成熟，它所需要功效也在不停地发展。一样，可见ESB产品可用性和功效也日趋完善。所以，在本系列最终一篇文章中，我将考虑SOA和ESB发展路线，以指导ESB功效和技术最初应用，而且叙述怎样选择循序渐进方法。ESB在SOA内工作角色即使我不计划深入讨论SOA定义（请参见HYPERLINK""\l"resources"参考资料），不过在这里概括一下大部分对SOA描述所适用标准是很有用：利用显式和实现无关接口来定义服务。利用强调位置透明性和可互操作性通信协议。封装可重用业务功效服务定义。HYPERLINK""\l"figure1"图1说明了这些标准。注意，即使Web服务技术很符合这些标准，但它并不是唯一符合这些标准技术。图1:SOA标准为了实现SOA，应用程序和基础架构全部必需支持SOA标准。启用SOA应用程序包含到创建服务接口，服务接口能够直接也能够间接地经过使用适配器用于现有或新功效。从最基础等级来看，启用该基础架构包含到计划功效来将服务请求路由和传输给正确服务提供者。然而，基础架构支持在不影响服务用户端情况下由另一个服务实现替换原有服务实现也是至关关键。这不仅需要依据SOA标准指定服务接口，而且需要基础架构许可用户端代码以独立于所包含服务位置和通信协议方法来调用服务。这么服务路由和替换是ESB很多功效中一部分。ESB支持这些服务交互功效，并提供集成通信、消息传输和事件基础架构来支持这些功效。所以，它将当今正在使用关键企业集成模式组合成一个实体。ESB为SOA提供和企业需要保持一致基础架构，从而提供适宜服务等级和可管理性、和异构环境中操作。本文剩下部分将讨论ESB在SOA中角色，包含它提供除了基础路由和传输以外功效，以下面ESB功效模型部分中所述。ESB结构ESB有时被描述为分布式基础架构，这和其它处理方案形成了对比，比如消息代理技术通常被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正差异。正在研究两个不一样问题：控制集中和基础架构分布。ESB和中心辐射型（hub-and-spoke）处理方案全部集中控制配置，比如服务交互路由、服务命名等等。一样，这两个处理方案可能布署在简单集中式基础架构中，也可能采取更复杂分布式方法进行布署。HYPERLINK""\l"figure2"图2展示了这一点。毫无疑问，不一样技术对它们所支持物理布署模式有不一样约束——有些可能适合于很广泛分布，以支持在很大地理范围内进行集成，而其它可能更适合于布署在当地群集中，以支持高可用性和可伸缩性。使物理分布需求和候选技术功效相匹配是ESB设计一个关键方面。另外一个能力也是很关键，就是以增量方法扩展最初布署