理解面向服务的体系结构中企业服务总线场景和解决方案.docx
《理解面向服务的体系结构中企业服务总线场景和解决方案.docx》由会员分享，可在线阅读，更多相关《理解面向服务的体系结构中企业服务总线场景和解决方案.docx（31页珍藏版）》请在冰豆网上搜索。
理解面向服务的体系结构中企业服务总线场景和解决方案
理解面向服务的体系结构中企业服务总线场景和解决方案
理解面向服务的体系结构中企业服务总线场景和解决方案1
第1部分企业服务总线中的工作角色1
第2部分驱动体系结构的ESB场景和问题9
第3部分ESB场景的解决方案15
第1部分企业服务总线中的工作角色
2004年7月01日
本文确定了一组最低功能，可以满足企业服务总线（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展示了这一点。
毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。
使物理分布需求与候选技术的功能相匹配是ESB设计的一个重要方面。
另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。
图2:
分布式ESB基础架构的集中控制
我还应该定位在SOA基础架构中ESB与其他组件之间的关系，特别是与ServiceDirectory、BusinessServiceChoreography、以及Business-to-Business（B2B）Gateway这些组件之间的关系。
由于上述SOA原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。
图3展示的SOA说明了这些组件之间的关系。
图3:
SOA中的ESB角色
ESB需要某种形式的服务路由目录（serviceroutingdirectory）来路由服务请求。
然而，SOA可能还有单独的业务服务目录（businessservicedirectory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。
Web服务远景在业务服务目录和服务路由目录的角色中都放置了一个UDDI目录，因而使得可以动态发现和调用服务。
这样的目录可以视为ESB的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与ESB是分离的。
BusinessServiceChoreographer的作用是通过若干业务服务来组合业务流程；因此，它将通过ESB调用服务，然后再次通过ESB将业务流程公开为客户端可用的其他服务。
然而，BusinessServiceChoreographer在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术ESB分离的技术。
最后，B2BGateway组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。
这有助于查看这些连接到ESB的组件，但它们并不是ESB的一部分。
虽然有一些网关技术可以提供适合于实现B2BGateway组件和ESB的功能，但是B2BGateway组件的用途是将其与ESB分离。
事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是ESB的一部分，并且不一定受到ESB技术的支持。
ESB的功能模型
表1对现有文献中确定的一些ESB功能进行了总结和分类（请参见参考资料）。
虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。
重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。
ESB实现所需的最低功能将在下面支持SOA的最低功能的ESB实现部分中进行探讨。
表1：
在现有的文献中定义的ESB功能
通信
服务交互
∙路由
∙寻址
∙通信技术、协议和标准（例如IBM®WebSphere®MQ、HTTP和HTTPS）
∙发布/订阅
∙响应/请求
∙Fire-and-Forget，事件
∙同步和异步消息传递
∙服务接口定义（例如，Web服务描述语言（WebServicesDescriptionLanguage，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功能
通信
集成
∙提供位置透明性的路由和寻址服务
∙控制服务寻址和命名的管理功能
∙至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）
∙支持至少一种可以广泛使用的传输协议
∙支持服务提供的多种集成方式，比如Java2连接器、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中间件服务器之间使用安全套接字层（SecureSocketLayer，SSL）互相验证，或者是否在使用HTTPS协议？
2.是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？
例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？
3.是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户ID和密码的基本HTTP身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？
4.是否需要遵守行业安全标准，例如Kerberos或WS-Security？
虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如Web服务安全性（WS-Security））功能。
然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。
因此，任何ESB架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。
结束语
在本文中，我讨论了大多数通用的SOA原则，以及它们与Web服务技术的关联。
基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。
这些功能都是通过ESB实现的。
ESB在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能需要业务服务目录。
BusinessServiceChoreographer从ESB调用服务，然后通过ESB把这些流程作为新的服务公开。
ESB的许多功能包括提供：
∙通信
∙服务交互
∙集成
∙质量服务
∙安全
∙服务级别
∙消息处理
∙管理及自治服务
∙建模
∙基础架构智能
从这些不同的功能中，我确定了建立ESB所需的最低功能，包括通信、集成和服务交互。
在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。
致谢
如果作者没有与下列人员进行讨论，就不会有本文的存在，他们中的所有人都为本文贡献了很好的想法和思想：
BethHutchison、RachelReinitz、OlafZimmerman、HelenWylie、KyleBrown、MarkColan、JonathanAdams、PaulFremantle、KeithJones、PaulVerschueren、DanielSturman、ScottCosby、DaveClarke、BenMann、LouisaGillies、EricHerness、BillHassell、GuruVasudeva、KareemYusuf、KenWilson、MarkEndrei、NorbertBieberstein、ChrisNott、AlanHopkins和YaroslavDunchych。
参考资料
∙您可以参阅本文在developerWorks全球站点上的英文原文.
∙要了解Web服务技术如何为实现面向服务的体系结构提供必要的基础，请阅读AnnraiOToole撰写的WebService-OrientedArchitecture-TheBestSolutiontoBusinessIntegration。
∙在CBDI论坛查阅由LawrenceWilkes撰写的文章SOA-SaveOurAssets（需要订阅）。
∙Patterns:
Service-orientedArchitectureandWebServices红皮书，SG24-6303-00，2004年4月，作者EndreiM.等。
∙阅读“迁移到面向服务的体系结构，第1部分”（developerWorks，2003年12月）和“迁移到面向服务的体系结构，第2部分”（developerWorks，2003年12月）。
∙访问LooselyC以获得企业服务总线（EnterpriseServiceBus）链接列表。
∙最初定义企业服务总线（EnterpriseServiceBus）的文章Gartner需要订阅，不过，也可以通过搜索它们的站点进行查找，该文章的标题为Predicts2003:
EnterpriseServiceBusesEmerge，2002年12月9日发布，作者RoyW.Schulte。
∙研究IBMPatternsfore-business网站。
∙访问IBM的按需商务（ondemandbusiness）以获得更多关于按需操作环境的详细信息。
∙本文所用的资料来自forthcoming红皮书Patterns:
ImplementinganSOAusinganEnterpriseServiceBus，SG24-6346-00，草案，作者MartinKeen等。
∙在developerWorks的SOAandWebservices技术专区查找其他SOA和Web服务技术资源。
∙在DeveloperBookstore购买关于各种各样的技术主题的打折图书。
关于作者
RickRobinson是IBM的一名IT架构师，他于1997年3月作为一名开发人员加入该公司。
他是EMEAWebSphereLabServices的ArchitectureServicesgroup的一位成员，他从1999年WebSphere软件平台首次发布时就开始关注它。
Rick更关注技术而不是行业，但是在过去的三年里他花了大量的时间和金融领域的公司一起工作。
Rick是IBM的一位值得信赖的IT架构设计专业人员。
在加入IBM之前，Rick在攻读物理博士。
第2部分驱动体系结构的ESB场景和问题
在关于企业服务总线（EnterpriseServiceBus，ESB）的这个系列的第二部分中，作者描述和分析了实现ESB和其他面向服务的体系结构（SOA）的解决方案的一些常见场景。
这个系列的第1篇文章描述了企业服务总线（EnterpriseServiceBus，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
∙
升级会员 