2021年面向服务的体系结构中企业服务范文

HYPERLINK""了解面向服务体系结构中企业服务总线场景和处理方案第1部分企业服务总线中工作角色HYPERLINK""\l"author1"RickRobinson（HYPERLINK"mailto:"）IT架构师,IBM年7月本文确定了一组最低功效，能够满足企业服务总线（EnterpriseServiceBus，ESB）和面向服务体系结构（service-orientedarchitecture，SOA） 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 保持一致基础需要。经过确定这些最低功效，您能够确定利用何种现有技术来实现支持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 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 一个关键方面。另外一个能力也是很关键，就是以增量方法扩展最初布署来反应不停改变需求、集成附加系统或扩展基础架构物理范围。图2:分布式ESB基础架构集中控制我还应该定位在SOA基础架构中ESB和其它组件之间关系，尤其是和ServiceDirectory、BusinessServiceChoreography、和Business-to-Business(B2B)Gateway这些组件之间关系。因为上述SOA标准对这些组件并没有严格要求，所以我们能够将它们视为可选组件。HYPERLINK""\l"figure3"图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功效模型HYPERLINK""\l"table1"表1对现有文件中确定部分ESB功效进行了总结和分类（请参见HYPERLINK""\l"resources"参考资料）。即使有部分功效很基础，不过其它功效（如自动化功效或智能化功效）代表着向按需操作环境转变关键步骤。关键是认识到，目前大多数场景只需要部分类别中部分功效。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提供了管理服务基础架构方法和在分布式异构环境中进行操作功效。HYPERLINK""\l"table2"表2展示了依据这些标准定义最低ESB功效表2:最低ESB功效通信集成提供位置透明性路由和寻址服务控制服务寻址和命名管理功效最少一个形式消息传输范型（比如，请求/响应、公布/订阅等等）支持最少一个能够广泛使用传输协议支持服务提供多个集成方法，比如Java2连接器、Web服务、异步通信、适配器等等服务交互一个开放且和实现无关服务消息传输和接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并许可替换服务实现。请注意这些最低功效并不需要使用尤其技术，比如EAI中间件、Web服务、J2EE或XML。这些技术使用很靠近也很符合需求，不过无须强制要求使用它们。相反，最低功效几乎只需简单地使用SOAP/HTTP和WSDL就能够实现（当然不是全部情况全部这么）：URL寻址和现有HTTP和DNS基础架构提供了一个含有路由服务和位置透明性“总线（bus）”。SOAP/HTTP支持请求-响应（Request-Response）通信 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 。HTTP传输协议被广泛地使用。SOAP和WSDL是开放、和实现无关服务通信和连接模型。然而，这些SOAP/HTTP和WSDL基础应用只是点到点（point-to-point）集成，并不能实现部分ESB需要关键功效：现在还没有用于控制服务寻址和命名管理功效。服务名称经过每个适配器单独进行控制，服务路由控制则分散在由服务用户端调用地址、HTTP基础架构和分配给适配器服务名称之间。即使这种方法依靠于实现细节，不过它往往并不能使服务实现替换变得简单；服务请求者代码（也可能是开发工具生成）通常经过特定地址特定协议直接绑定到具体服务提供者实现。假如想要用另一个服务实现来替换原来服务实现，就需要修改应用程序代码并重新布署这些代码。当然，在很多甚至是大多数情形中往往需要其它功效，而且这种需要变得越来越常见。尤其地，不管是现在还是以后，下面需求类型可能会造成更复杂高级技术使用：服务质量和服务等级功效。高级SOA概念，比如服务编排、目录、转换等等。按需操作环境需求，比如管理和自治功效和基础架构智能功效。跨越含有不一样全部权多个网络、多个协议和多个域真正意义上异步操作。影响ESB安全问题我不想在这里直接提出安全需求，不过它们对选择ESB实现技术很关键。比如，假如服务请求不需要提供身份验证或授权，实现技术选择就能够很广泛。更有可能情况是，假如需要部分安全等级，则评定什么形式安全是能够接收就很关键。比如：是否能够接收通信基础架构中安全性，比如，是否在EAI中间件服务器之间使用安全套接字层（SecureSocketLayer，SSL）相互验证，或是否在使用HTTPS协议？是否能够接收在参与系统之间单独点到点（point-to-point）安全性，或是否需要端到端（end-to-end）模型？比如，是否有必需经过类似于代理中间件系统来把用户端身份传输到服务实现最终提供者？是否能够接收应用层中安全性，比如，用户端代码是否能够实施带有用户ID和密码基础HTTP身份验证，或是否能够把这些信息作为应用程序数据传输给服务？是否需要遵守行业安全标准，比如Kerberos或WS-Security？即使全部这些全部是可能，不过行业发展方向是基础架构和中间件支持符合标准安全性（比如Web服务安全性（WS-Security））功效。然而，相比之下，这些安全标准也是最近才提出，而且对它们产品支持仍在发展过程中，而不是已经确定了，这里尤其需要尤其考虑就是它们互操作性。所以，任何ESB架构全部需要尽可能早地确定安全需求，方便在选择实现技术时能够将它们包含进来。结束语在本文中，我讨论了大多数通用SOA标准，和它们和Web服务技术关联。基于这些标准，我提出了需要一个基础架构组件，这个组件能够提供路由功效，方便使服务能够相互交互，同时还能够支持使用另一个服务实现来替换原有服务实现。这些功效全部是经过ESB实现。ESB在维持集中控制同时提供分布式基础架构，所以需要部分形式服务路由目录，而且还可能需要业务服务目录。BusinessServiceChoreographer从ESB调用服务，然后经过ESB把这些步骤作为新服务公开。ESB很多功效包含提供：通信服务交互集成质量服务安全服务等级消息处理管理及自治服务建模基础架构智能从这些不一样功效中，我确定了建立ESB所需最低功效，包含通信、集成和服务交互。在这个系列下一个部分中，我将讨论部分通用场景，和和这些场景相关处理方案模式，同时指出影响这些场景最通常问题。第2部分驱动体系结构ESB场景和问题HYPERLINK""\l"author1"RickRobinson（HYPERLINK"mailto:"）ITArchitect,IBM年7月在相关企业服务总线（EnterpriseServiceBus，ESB）这个系列第二部分中，作者描述和分析了实现ESB和其它面向服务体系结构（SOA）处理方案部分常见场景。这个系列HYPERLINK""第1篇文章描述了企业服务总线（EnterpriseServiceBus，ESB）基础概念和工作角色。本文侧重于描述为支持面向服务体系结构（SOA）而进行ESB开发场景和问题。您组织SOA和ESB可能需要应用到一个或多个这么场景。ESB场景及分析SOA中ESB场景部分描述了很多SOA和ESB实现起点。每个场景全部指出驱动体系结构和设计决议问题，而这些决议会影响处理方案模式选择（将在这个系列第3部分中进行介绍）。在HYPERLINK""\l"2.2"驱动ESB体系结构和设计决议问题部分中，您能够阅读相关这些问题具体描述。这些处理方案模式代表着从服务技术基础使用，到简单ESB实现，再到复杂SOA体系结构发展过程。这些ESB场景目标并不在于展示组织对SOA或ESB全部需求。比如，即使某个场景（如两个系统基础集成）可能看起来很好地匹配了特定目前需求，不过伴随时间推移，这种需求可能发展成更复杂需求（如支持一个或多个应用程序实现更广泛连接性场景。另外，还可能有很多对SOA或ESB基础架构单独需求会出现这么情况，就其部分而言符合简单场景，但集中在一起则表现得比较复杂。我们需要在实现满足很明确需求处理方案、努力预料未来需求和定义跨企业一致处理方案这三者之间作出选择。将组织需要看作是总体上相对复杂场景（如实现含有高服务质量和Web服务标准支持SOA基础架构）可能是比较适合。另外，还能够将部分情形单独看作是简单场景，不过定义最终得到这些处理方案以后发展成通用体系结构路线。SOA中ESB场景下面多个部分描述了这些场景特征：HYPERLINK""\l"table1"两个系统基础集成HYPERLINK""\l"table2"支持一个或多个应用程序实现更广泛连接性HYPERLINK""\l"table3"支持遗留系统实现更广泛连接性HYPERLINK""\l"table4"支持企业应用程序集成（EAI）体系结构实现更广泛连接性HYPERLINK""\l"table5"实现组织之间服务或系统受控集成HYPERLINK""\l"table6"经过编排服务使步骤自动化HYPERLINK""\l"table7"实现含有高服务质量和Web服务标准支持SOA基础架构两个系统基础集成场景企业需要提供用不一样技术（如J2EE、.NET、CICS等等）实现两个系统之间集成。Web服务SOAP标准或消息传输中间件可能是候选集成技术。这个场景一个关键问题是，未来是否会出现需要集成其它系统情况。一开始就使用可扩展处理方案可能会对未来需要提供支持；不过必需在为构建这么处理方案而付出额外工作和处理简单问题最初需要之间保持平衡。最相关问题相关处理方案模式（请参见下一篇文章）1,3,4,6,10,13使用包装器或适配器来实现基础集成—请参见基础适配器。或，想要在未来进行扩展，有以下两种方案：添加控制服务网关。或实现一个复杂基础架构—比如WebservicesCompliantBroker或EAIInfrastructureforSOA。支持一个或多个应用程序实现更广泛连接性场景现有已封装或自定义开发应用程序（比如用户关系管理（CustomerRelationshipManagement，CRM）、企业资源计划（EnterpriseResourcePlanning，ERP）等等）可能是用J2EE平台或其它应用程序服务器环境实现，它们提供可用功效超出了应用程序本身。以服务形式公开这些功效价值在于，既支持应用程序相互之间互操作，也提供对新通道或用户端访问。使用可互操作或开放标准通信和服务协议看来是以后发展最好路径。最相关问题相关处理方案模式（请参见下一篇文章）1、2、3、4、6、8、9、10、11、12、13、14使用包装器或适配器来实现基础集成—请参见基础适配器。添加控制服务网关。或实现一个复杂基础架构—比如WebservicesCompliantBroker或EAIInfrastructureforSOA。假如还需要步骤编排（ProcessChoreography），就实现ServiceChoreographer或FullSOAInfrastructure。支持遗留系统实现更广泛连接性场景组织对遗留技术（比如CICS、IMS等等）进行了大量投资，以支持为她们提供关键业务事务和数据访问应用程序。其关键价值在于提供互操作性或开放标准、和对这些事务进行基于服务访问（比如，查询帐户余额事务、创建订单、日程安排或交付跟踪、查询库存等级等等）。最相关问题相关处理方案模式（请参见下一篇文章）1,2,3,4,7,8,9,10,11,13,14使用包装器或适配器来实现基础集成—请参见基础适配器。或，想要在未来进行扩展，有以下两种方案：添加控制服务网关。或实现一个复杂基础架构—比如WebservicesCompliantBroker或EAIInfrastructureforSOA。支持企业应用程序集成（EAI）基础架构实现更广泛连接性场景需要对现有EAI基础架构（如IBMWebSphereBusinessIntegration）进行扩展，以对其进行基于可互操作协议或开放标准访问。即使依据XML业务数据并经过高度可互操作协议（如HTTP或WebSphereMQ）公开服务接口能够在一些场景中提供合适互操作性等级，不过假如对现有集成范围自定义开发或专有扩展全部不是可接收，则可能需要支持WSDL和SOAPWeb标准。最相关问题相关处理方案模式（请参见下一篇文章）3、4、5、8、9、11、13、14使用开放数据格式及EAIInfrastructureforSOA来扩展EAI基础架构。添加控制服务网关。或对带有WebservicesCompliantBroker基础架构增加开放标准支持。实现组织之间服务或系统受控集成场景组织期望使其用户、供给商或其它合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供功效。控制关键是需要提供从外部各方到这些应用程序安全且易管理访问。因为组织不能直接控制其合作伙伴所使用技术，所以最好使用开放标准。此场景既能够应用于分散组织之间，也能够应用于大型分布式组织各个单位之间。最相关问题相关处理方案模式（参见下一篇文章）1、2、3、4、6、8、9、10、11、13、14添加服务网关。或假如需要更多复杂功效，就实现WebServicesCompliantBroker。经过编排服务使步骤自动化场景（注意：此场景能够看作是支持一个或多个应用程序实现更广泛连接性场景发展。它不被看成一个ESB场景，因为服务编排通常是和ESB分开实现，正如本系列第一篇文章所述。然而，我之所以把它包含在这里，是因为此场景往往驱动对ESB和服务编排组件需求。）现有已封装（比如，用户关系管理（CustomerRelationshipManagement，CRM）、企业资源计划（EnterpriseResourcePlanning，ERP）等等）或自定义开发应用程序可能是在J2EE平台或其它应用程序服务环境中实现，它们提供可用功效超出了应用程序本身。能够使用可互操作或开放通信和服务协议将这些功效作为服务公开，这么应用程序就能够交互。能够在一些层次上组合这些交互以组成业务步骤。应该使用合适建模和步骤实施技术（可能遵守合适开放标准）来对这些步骤进行显式建模。最相关问题相关处理方案模式（请参见下一篇文章）1、2、3、4、6、10、11、12、13、14假如服务直接连接是可能，则实现ServiceChoreographer。假如需要更复杂集成或控制，则实现FullSOAInfrastructure。实现含有高服务质量和Web服务标准支持SOA基础架构场景此场景是由前面组成。它代表了对由多个应用程序、遗留系统等等提供服务进行普遍内部或外部访问需要。需要多种安全、聚合、转换、路由和服务编排功效。IT组织以响应所支持业务不停增加需求，从而使得能够在业务系统之间进行更普遍且更灵活集成。最相关问题相关处理方案模式（请参见下一篇文章）全部实现FullSOAInfrastructure。驱动ESB体系结构和设计决议问题为了确定用于ESB适宜处理方案模式和实现技术，需要对特定ESB功效需求进行具体分析。下面问题意在帮助进行这一过程，而前面部分指出了和每个场景相关特定问题。现有功效及其数据接口是否和您想要提供服务相匹配？您是否能够修改或聚合应用程序？假如不能够，则转换或聚合功效就需要由适配器或ESB体系结构来提供，或不得不由服务用户端来完成。服务是否能够以部分通用业务数据模型形式公开？假如能够，则实现这些服务系统是否已经支持该模型？或说能够使它们这么做？假如服务不能够，则转换或聚合功效就需要由适配器或ESB体系结构来提供。是否需要开放标准？或是否能够经过EAI中间件来实现合适互操作性？假如需要开放标准话，则哪些开放标准是适合？即使使用开放标准是实现互操作性一个路径，但专有EAI中间件也含有高度互操作性，而且往往要成熟得多。另外，很多组织还拥有广泛现有基础架构，在部分场景中，它们可能会使得开放标准作用几近于无。在需要开放标准场景中，Web服务可能是这些情况下最显著选择。不过，您也能够应用JavaMessagingService(JMS)、JDBC、基础XML或部分其它技术（比如EDI或业界通用XML格式。在实践中，不能总是假定相同标准不一样实现之间含有互操作性，尤其是对于最近出现或刚刚兴起标准。对于Web服务，Web服务互操作性组织（WebServicesInteroperabilityOrganization）公布了使用SOAP和WSDL互操作性基础概要，其它更高级标准（比如Web服务安全性（WS-Security）、Web服务事务（WS-Transaction）等等）概要随即也将公布。在产品全方面、稳定且广泛地支持这些概要之前，开放标准使用还没有得到确保，而且可能并不总是促进互操作性。是否需要支持基础通信协议及标准（比如WebSphereMQ、SOAP、WSDL）？或需要更高级功效（比如Web服务安全性（WS-Security）、Web服务事务（WS-Transaction）等等）？对支持更复杂标准需求将对实现技术选择加以更严格约束，而且可能意味着使用还不成熟技术。当果考虑更改现有基础架构使用消息格式和协议（包含可能采取开放标准）时，需要在整个现有基础架构中进行这些更改吗？或很快就要应用新消息格式和协议吗？假如正在使用或考虑使用EAI技术，该技术是否有自己内部格式？或它能够将开放标准处理为内部格式吗？开放标准任何应用全部是受扩展访问需求驱动，所以它们对现有基础架构接口可用性比在内部使用这么标准更关键。假如需要在内部使用特定格式、技术或标准，这会给实现技术选择带来限制。将作为服务公开系统实现功效支持所需技术或开放标准（比如SOAP、JMS或XML）吗？假如不支持，ESB基础架构或适配器将需要在所需开放标准和服务提供者支持格式之间进行转换功效。在需要访问遗留系统情况下，经过使用更新基于XML技术，能够直接支持（比如CICSSOAP支持）遗留系统可用性吗？是否需要单独适配器？遗留平台是否支持XML处理？假如支持，这种处理是否能够灵活地使用平台功效？假如因为这其中任何原所以造成所需SOAP或XML功效对遗留平台不可用，则需要在适配器（比如sJ2CConnectorArchitecture(JCA)或WebSphereBusinessIntegrationAdaptors）、集成层或ESB基础架构中使用合适转换功效。假如EAI技术已经可用，它是否使用合适功效或接口粒度将服务作为消息流实现？它支持哪些连接性协议（比如JCA、SOAP、WebSphereMQ和Java远程方法调用（JavaRemoteMethodInvocation））？假如现有消息流不提供所需要服务，则需要另外步骤来实施转换。假如EAI技术不直接支持所需标准，就需要添加一个网关组件。应该从服务用户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护方法？这种缓冲通常是ESB基础架构一个角色，而且定义它所需要部分功效。假如特定服务提供者系统（比如遗留事务系统（legacytransactionalsystems））需要额外保护，则能够使用专用集成层。应该实现多少服务？实现什么方面应该在这些服务中保持一致？怎样实施一致性（可能在多个平台上和多个应用程序中）？假如只需要很少服务，简单点到点（point-to-point）集成模型可能比较适合。然而，假如需要更多服务或过一段时间以后可能还是如此，则添加控制点（比如由ESB提供）就变得愈加有益。服务交互包含在组织内部，还是有部分交互在组织外部？这常常是不一样于在单个组织中实现ESB基础架构一个情况，因为对安全和服务路由需求可能和外部可用服务不一样。是否需要服务编排？服务编排是否包含短期（short-lived）或长久（long-lived）（换句话说就是有状态）步骤，还是二者全部包含？它们是否包含人工活动？在这些需求组成业务功效情况下，应该在和ESB分离ServiceChoreographer组件中实现编排。相关是支持长久有状态步骤还是支持人工活动需求将对实现技术选择产生限制。基础架构应该支持什么样服务级需求（比如，服务响应时间、吞吐量、可用性等等）？伴随时间推移，需要怎样对其进行扩展？部分候选ESB实现技术相对较新，而且可能仅仅在有限服务级进行过测试。一样，因为相关开放标准不是最近制订就是正在兴起，所以在更多既定产品和技术中对它们支持也是新出现。在能够预见未来，关键体系结构决议将专注于特定开放标准优点平衡，针对服务级需求新兴或成熟产品技术支持这些开放标准。制订这些即时决议需要考虑到有些标准和支持它们产品是相对成熟（比如XML、SOAP等等），有些（比如Web服务安全（WS-Security））比较新，还有部分（比如Web服务事务）是正在兴起。标准优点之间权衡和经过验证服务级特征往往驱动一个结合了ESB和SOA体系结构中适应标准、专有或自定义技术混合方法。是否需关键点到点（point-to-point）或端到端（end-to-end）安全模型（比如，ESB是否能够简单对服务请求授权，还是需要将请求者身份或其它凭证传输给服务提供者）？是否需要使用应用程序或遗留安全系统来集成服务安全模型？假如点到点安全性是可接收，则很多现有处理方案（比如SSL、对数据库访问J2EE安全性、适配器安全模型等等）就能够得到应用。假如需要端到端安全性，则Web服务安全标准就成为可能，提供全部相关系统来支持它。换句话说，您能够使用带有用户端消息头用户端模型，或传送像应用程序数据这么安全信息。结束语本文确定了部分ESB实现中最常见场景，和对对应处理方案直接产生影响问题。即使没有完全涵盖全部隐藏问题，但这些是其中最常碰到。我们概述了从两个系统基础集成到实现支持高质量服务和Web服务标准SOA体系结构常见场景。并描述了需要重视十四个不一样问题：现有数据接口业务数据模型开放标准使用对基础或高级通信协议支持经过现有系统对数据传输格式修改经过新技术公开现有服务对遗留系统访问现有EAI技术需要保护方法需要提供多少服务和需要一致性程度企业内部和和其它企业之间互操作对服务编排需求服务级需求基础架构级支持点到点（point-to-point）或端到端（end-to-end）安全模型使用了解这些基础场景和问题为您开发可能处理方案打下了牢靠基础。在本系列第3部分，我将讨论本文中提到实际处理方案。以下：基础适配器服务网关WebservicesCompliantBrokerServiceChoreographer用于SOAEAI体系结构完整SOA体系结构最终，我将讨论组织考虑怎样使用受控和增量方法发展它们体系结构时可用选择。也将说明能够指导您开发自己ESB路线部分问题。了解面向服务体系结构中企业服务总线场景和处理方案，第3部分ESB场景处理方案等级:初级HYPERLINK""\l"author1"RickRobinson（HYPERLINK"mailto:"）ITArchitect,IBM年7月这个系列文章第3部分介绍了实现企业服务总线（EnterpriseServiceBus，ESB）场景和处理方案，在此作者分析了HYPERLINK""第2部分概述多个场景可能处理方案。HYPERLINK""在第1部分中说明总线工作角色提供了这些场景基础。下面继续这个系列来构建面向服务体系结构（Service-OrientedArchitecture，SOA）企业服务总线，现在我们来看一看第2部分（请参阅HYPERLINK""\l"resources"参考资料）中所描述场景多个显而易见处理方案模式。以下每个部分全部描述了一个ESB实现方法处理方案模式，除了基础适配器（BasicAdaptors）模式以外，其它全部是简单点到点（P2P）处理方案。每个模式全部提出了不一样使用现行技术实现选择，同时也做出了正反两方面和移植方面考虑。请注意每个处理方案模式图示，它认为服务用户端和提供服务系统是分离。当然，在很多情况下，相同系统或应用程序既能够是服务用户端也能够是服务提供者。图示并非是要排除系统作为单独用户端和提供者可能性，而是认可了相同系统在不一样互操作中能够有两种不一样工作角色。在决定系统是作为用户端角色来选择、确定和调用服务，还是作为提供者角色来接收、处理和响应服务请求时，这个区分通常很关键。本部分处理方案模式有：基础适配器（BasicAdaptors）服务网关Web服务兼容代理（WebService-compliantBroker）面向服务体系结构企业应用集成基础架构（EAIInfrastructureforSOA）服务编排（ServiceChoreographer）完整面向服务体系结构基础架构（FullSOAInfrastructure）基础适配器处理方案模式这种处理方案经过封装器或适配器技术来实现简单点到点（P2P）服务集成，而不是真正ESB。这种技术经过WSDL定义SOAP访问或其它可互操作产品技术（比如IBMWebSphere®MQ（MQ））来实现集成。假如这些技术没有为服务接口定义（比如WSDL）提供当地模型，那么将需要使用自定义模型来实现SOA规范。即使设计比较简单，不过从该模式中能够取得好处却不可低估。比如，经过MQ或SOAP/HTTP进行直接集成仍然能够是松散耦合式，尤其是互操作特征是使用接口来申明时。在未来某个时候，对于支持最初使用集成技术ESB基础架构，我们能够经过它来中止集成。还能够在进程等级服务命名和寻址之上实现控制等级。现在已经有多种多样适配器可用，而且也能够经过开发工具或运行时技术来创建新适配器。并能使其提供对Web服务规范和企业应用集成（EnterpriseApplicationIntegration，EAI）中间件支持。它也能够提供给多个不一样类型系统，包含最新分布式应用服务器（J2EE服务器（如WebSphere），或微软.NET系统）、企业遗留系统（比如CICS®）和CommercialOff-the-Shelf软件包（比如SAP或Siebel）。HYPERLINK""\l"figure4"图1说明了通常基础适配器处理方案，包含了使用现有HTTP和EAI中间件基础架构来支持新集成。即使本图描绘是内部集成场景，但假如用HTTP来作为通信协议，或使用一些Internet兼容EAI技术（比如MQinternetpass-thru），那么该处理方案一样能够应用于外部场景。图1.基础适配器处理方案模式将现有HTTP和未修改EAI基础架构描述为支持服务总线功效一些方面选择基础适配器实现技术以下是实现基础适配器部分选择：使用遗留系统或应用程序直接提供SOAP或EAI功效。比如，IBMCICS现在直接提供对SOAP支持，和很多系统和应用程序包能够支持MQ或SOAP接口。假如用于提供访问应用程序是用户自己开发应用程序且运行于应用服务器环境，或只要应用服务器运行时环境和应用开发环境能够用来给应用程序添加封装器。比如，WebSphereStudioApplicationDeveloper能够用来给布署于WebSphereApplicationServer（ApplicationServer）J2EE应用程序添加XML、SOAP或MQ支持。假如这种支持不可用或不适宜（比如，假如XML转换不适适用来处理现有平台上资源），那么可能需要其它体系结构层，如HYPERLINK""\l"figure5"图2所表示。这可能是托管了和应用程序或遗留系统集成适配器应用服务器层。比如，ApplicationDeveloperIntegrationEdition提供了Java2连接器架构（Java2ConnectorArchitecture，JCA）连接器技术来访问遗留系统（比如CICS），并经过WebSphere运行时环境为其提供了J2EE和Web服务接口。图2.实施XML转换处理其它体系结构层假如使用开发工具来创建自己封装器，那么您能够增强工具提供功效：经过创建一个框架或一组实用工具类来实施通用任务，比如安全性、日志纪录等等。然而，这种方法可能引发范围蠕变（scopecreep），并最终造成该框架实际上变成了用户开发HYPERLINK""\l"2"服务网关或HYPERLINK""\l"3"Web服务兼容代理。当定义框架提议功效时，需要注意验证开发和维护成本是否适宜，和转换为更复杂模式是更不适宜。请参阅HYPERLINK""\l"resources"参考资料以获取更多相关实现此模式具体信息。基础适配器剖析从正面来说，这种处理方案模式对新基础架构需求最低或是根本不需要，而且使用全部是广泛支持多种规范和技术。从反面来说，像安全、管理等功效全部交给了应用程序或单个封装器实现来处理。因为该模式基于使用协同操作技术和开放式标准，所以将该模式移植到更复杂体系结构也就相对比较简单。模式替换假如以上均不能满足集成需求，或存在部分附加功效或服务质量需求，那么封装器方法就可能满足不了需求。假如是这么，从逻辑上说下一步应该是HYPERLINK""\l"2"服务网关。假如需要更高级ESB功效，则HYPERLINK""\l"3"Web服务兼容代理或HYPERLINK""\l"4"EAIInfrastructureforSOA模式会比较适合。服务网关处理方案模式这种模式代表了一个基础ESB实现，靠近于在HYPERLINK""\l"2.2"第1部分中描述“最低功效ESB实现”。服务网关通常经过SOAP/HTTP、MQ、Java消息服务（JavaMessageService，JMS）等来支持用户端连接，不过也能够经过诸如JCA或WebSphere业务集成适配器（WebSphereBusinessIntegrationAdaptors，WBIA）来对服务提供者支持更广泛集成。网关组件为服务路由、协议转换和安全担当着中央控制点角色。网关能够用来向用户端提供一致服务命名空间（比如，以URL形式为SOAP/HTTP服务提供命名空间），并能够向服务提供授权模型，实际上这些服务是由完全不一样系统经过多个协议来提供。当需要向外部合作伙伴（比如用户端或供给方）公开服务时，网关所提供这些功效便成为一个显著需求。然而当需要对从应用程序到用多个系统和技术实现功效访问进行简化时，这些功效在单个企业内部也很有用。一个关键网关功效是将用户端支持服务协议转换为提供方支持服务协议。这些协议能够包含SOAP/HTTP、MQ或SOAP/JMS、JCA、RMI/IIOP等。候选实现技术能力需要针对所需要用户端和提供方协议来进行评价。HYPERLINK""\l"figure6"图3描述了服务网关处理方案模式图3.使用服务网关模式实现ESB选择服务网关实现技术服务网关处理方案模式能够用以下方法来实现：使用打包好网关技术，比如WebSphereApplicationServerNetworkDeployment或WebSphereBusinessIntegrationConnection提供WebServicesGateway。很多网关技术支持一些形式中间件过滤器或处理器程序设计模型，以实现自定义增强功效。WebServicesGateway提供了部分可配置中间件功效。它也支持基于XML远程过程调用JavaAPIs（JavaAPIsforXML-basedRemoteProcedureCall，JAX-RPC）规范中定义Web服务请求/响应处理程序。使用应用程序开发和最新应用服务器技术运行时功效来实现自定义网关。这可能包含和前面HYPERLINK""\l"1"基础适配器处理方案模式中所描述相同类型适配器。假如需要更高级功效，就应该考虑更复杂高级EAI中间件，比如WebSphereBusinessIntegrationMessageBroker。这种模式很多实现存在于遗留技术中，这些遗留技术通常没有使用Web服务技术。比如，很多组织构建了路由器事务，它对多个遗留事务提供了使用类似文本（text-like）数据模型简单接口。这种系统使用含有部分XML可移植优点自定义数据格式，从而有效地实现了网关模式。服务网关剖析从正面来说，尽管部分网关技术必需在有合适弹性方法下布署，但这种处理方案仍然能够包含最低功效基础架构。对互操作协议和开放标准重视也使基础架构所包含方面得以简化。大多数网关技术和很多其它接口类型（比如RMI/IIOP和JCA）进行协同操作能力，也应该能够降低其它连接性技术布署。然而，网关技术往往限制了对请求/响应和公布/订阅服务简单一对一映射服务处理。更复杂高级功效，比如消息转换、消息相关性、消息聚集等全部可能超出了网关技术所能提供功效之外，或需要在自定义场景中进行网关技术之外开发工作。大多数ESB技术认可网关模式及其相关功效。有了这一点，互操作协议和开放标准使用、网关功效简化等任何移植到更高级ESB基础架构问题全部不会太困难。服务网关替换模式最显而易见替换模式是HYPERLINK""\l"3"Web服务兼容代理或HYPERLINK""\l"4"EAIInfrastructureforSOA。当需求超出了网关所能提供功效之外，或超出了已打包网关技术范围时，这些模式会比较适合。其次，假如实际包含服务很少，那么简单HYPERLINK""\l"1"基础适配器处理方案可能比较适宜。Web服务兼容代了处理方案模式这种处理方案代表了高级复杂ESB实现，它提供了一个功效完整EAI处理方案全部功效，而且使用开放标准模型。经过特定场所明确需求来定义需要什么等级EAI功效，从而确定适合使用哪种EAI技术。HYPERLINK""\l"figure7"图4说明了使用Web服务兼容代理ESB实现。图4.使用Web服务兼容代理特征丰富ESB实现选择Web服务兼容代理实现技术HYPERLINK""\l"3"Web服务兼容代理能够使用实现技术选择以下：最可能用于这种处理方案实现技术是能提供适宜Web服务支持EAI中间件，比如WebSphereBusinessIntegrationServer。假如Web服务支持关键是为了外部集成需要，则EAI中间件专有特征能够在内部使用，并结合HYPERLINK""\l"2"服务网关组件使用来添加Web服务支持。请参阅HYPERLINK""\l"resources"参考资料以获取更多相关实现此模式具体信息。Web服务兼容代理剖析这种实现方法优点是在开放标准模型内提供了丰富功效。然而，即使EAI中间件技术是成熟，不过该处理方案支持开放标准，尤其是更高级Web服务标准，比如Web服务策略（WS-Policy）和Web服务事务（WS-Transaction）还不够成熟。所以该场景最关键缺点仅仅是不能简单地对全部情况全部适用。Web服务兼容代理替换模式假如不能提供合适Web服务支持，则服务总线（ServiceBus）需求能够经过HYPERLINK""\l"4"EAIInfrastructureforSOA模式用愈加专有或定制方法来实现，可能要和服务网关组件相结合以添加Web服务接口。另外，假如开放标准是最关键需求，而且部分EAI功效（比如转换和聚集）能够在别处完成（可能是在应用程序或适配器内），则HYPERLINK""\l"2"服务网关模式可能更适宜。EAIInfrastructureforSOA出于本文一直讨论原因，采取Web服务规范并不总是适合。不过SOA标准却仍然能够应用于多种处理方案，这些处理方案既能够是专有或自定义技术，也能够是开放标准。一个显而易见方法已经被很多成功实现所证实。就是使用EAI技术（但不排除其它技术）并结合XML来构建自定义SOA基础架构。只要服务接口已经明确定义并有适宜粒度，EAI中间件就能确保满足SOA互操作性和位置无关性标准。这种方法潜在好处也意义重大，因为成熟EAI技术全部功效和性能全部应用于SOA灵活性上。这个优点既能够应用于为SOA实现新且坚固稳定基础架构，也能够应用于在现有基础架构上实现符合SOA标准应用程序。用这种方法实现ESB能够使用这些关键开放式，而且也是实际上标准，而且从它们中取得好处。实际上，这确实是一个能够把这些标准广泛应用到现有IT基础架构中方法，而且为未来更远发展提供一定基础：很多EAI技术应用很广泛，尤其是在单独组织中，以至于EAI技术和开放标准一样含有互操作性上优点。假如适宜话，能够使用XML数据和消息格式以帮助实现互操作性和平台无关性，就像XML在Web服务规范中帮助实现了这些优点一样。EAI将很有可能支持部分形式Web服务，所以能够在适合场所提供开放标准接口，尤其是对于使用document/literalSOAP模型来公开所使用XML格式场所。另外，能够经过添加HYPERLINK""\l"2"服务网关到该处理方案来提供这种访问。有些时候，能够利用Java平台无关性来提供用户端API包，这不仅对于J2EE环境来说很有用，而且对于单独Java环境、支持Java数据库环境和其它很多场所也是如此。EAI中间件能够支持其它开放标准（比如JavaMessagingService），这些标准可能不像Web服务那样广泛适用，但仍然有很多技术支持它们。该方法是向完全开放标准SOA基础架构发展一个关键步骤。即使从某种意义上说，最少应该考虑将其移植到Web服务标准，但这种方法是向完全开放标准SOA基础架构发展一个关键步骤。EAI和XML技术过渡使用最少提供了处理问题（比如接口粒度、公共数据模型和格式等）方法，全部这些全部是向前发展关键步骤。最终，再次强调这种方法好处。成熟EAI技术经过已被证实性能、可用性和可伸缩性等特点提供了极其丰富ESB功效（步骤和数据模型、转换、基于内容路由、服务聚集和编排等等）。因为这些功效是最关键需求，所以不借助Web服务技术而只使用EAI技术来实现ESB，这从处理方案关键上看是完全符合要求，尤其是因为假如需要使用Web服务，能够在很多方面添加Web服务支持。HYPERLINK""\l"figure8"图5说明了这种处理方案模式包含组件。图5.使用EAI中间件实现功效丰富服务总线选择EAI中间件模式实现技术EAI中间件选择取决于特定情况下所需ESB功效和多种不一样EAI产品（比如WebSphereBusinessIntegration家族）特征。设计活动关键之处于于服务接口定义模型。为了遵照SOA标准，应使用直接接口来定义服务。即使有些EAI技术可能提供了这么模型，但在其它情况下，需要自定义处理方案。在实践中，这常常经过使用XML模式并结合服务身份确定、寻址和业务数据来实现。然而，也有不使用XML处理方案，比如一些HYPERLINK""\l"2"服务网关模式遗留系统实现所使用文本处理方案。和数据模型无关接口模型方面功效，用于申明性地定义应该怎样使用EAI基础架构特征来调度服务请求和响应。应用程序需要部分机制以解释接口定义及合适调用EAI基础架构。还有，这些机制能够经过EAI技术提供，可供选择技术包含设计和开发规范实施，或框架API使用。框架API开发和维护显然代价不菲，不过它比实施跨越多个应用程序规范要更有效。假如最少大多数连接到服务总线应用程序全部支持同一个编程语言（比如Java）情况下，这么方法是最有效。业务数据模型采取也一样需要选择，是采取基于XML、专有还是自定义。因为存在很多一般和具体于特定行业XML数据模型，采取这些模型中一个可能会有好处。然而，很多这种模型正处于向Web服务规范移植过程中，假如考虑使用这种处理方案模式原因是因