第1部分企业服务总线中的工作角色RickRobinson(rick_robinson@uk.ibm),IT架构师,IBM简介：本文确定了一组最低功能，可以满足企业服务总线（EnterpriseServiceBus，ESB）与面向服务的体系结构（service-orientedarchitecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持SOA的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。引言最新的IT集成是使用Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（EnterpriseServiceBus，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展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分...