基于ESB的SOA-解决方案

基于ESB的SOA解决方案引言除了最简单的解决方案以外，企业服务总线是所有基于面向服务的体系结构解决方案的核心组成部分。那么ESB究竟是什么呢？您可以在整个IT行业中找到许多定义。本文章从IBM的角度（或者更准确地说，是在IBMSOAFoundation的上下文中）定义企业服务总线。本文章用抽象的术语讨论ESB并避免讨论产品细节；也就是说，本系列不讨论IBMWedSphereESB产品或ESB模式的任何其他实例。这种与产品无关的方法可以提供一个广泛的基础，以便了解ESB为面向服务的解决方案带来了什么，以及评估作为此类解决方案组成部分的特定ESB产品和相关技术。本文为整个系列奠定基础，讨论ESB在IBMSOAFoundation中的定位，并描述Foundation的其他部分如何与ESB相关。特别是，本文将确定ESB的核心原则。最后，本文为您提供ESB的初步内部细节，并说明ESB如何实现这些核心原则。IBMSOAFoundation和ESBIBMSOAFoundation是一个全面的体系结构和一组产品、技术和实践，用于处理SOA所包含的重要方面。SOAFoundation描述了：业务与IT部门之间的整体关系用于对业务设计建模的工具和方法用于使用IT系统来实现业务设计的工具、编程模型和技术用于承载某个实现的中间件基础设施该实现的管理，以确保其对业务的可用性，并确保在执行该实现的过程中高效地使用各种资源治理系统，用于控制业务设计方面的变更及其在IT系统中的实现要了解SOA的全部价值，您需要从不同的角度研究SOA。类似地，必须从不同的角度研究ESB的作用才能了解其全部价值。图1显示了SOAFoundation参考体系结构逻辑模型视图。该逻辑模型视图对SOA解决方案的功能基础进行了分解。这个功能性的或以IT为中心的视图将ESB描绘成一个集成部分，此部分提供解决方案的其他IT部分之间的互连。图1.IBMSOAFoundation参考体系结构逻辑模型视图图2显示了SOAFoundation参考体系结构解决方案视图。这是一个面向服务的解决方案的以业务为中心的视图。请注意，ESB被描绘成一个集成层，用于支持解决方案的业务组成部分之间的互连。图2.IBMSOAFoundation参考体系结构解决方案视图图1和图2都表明ESB是Foundation参考体系结构中的一种关键体系结构模式，并支持面向服务的解决方案中的服务请求者与服务提供者之间松散耦合的互连。松散耦合允许实现解决方案组成部分之间彻底的关注事项分离（时间、技术和组织上的分离），从而同时支持业务流程和IT系统的灵活性和敏捷性。本文的其余部分将详述该体系结构模式的特征以及如何能够实现这些特征。ESB核心原则图3显示了服务请求者、服务提供者和ESB之间的逻辑关系。服务请求者和提供者通过交换消息进行交互。充当交互中的逻辑中间层的ESB提供了功能的请求者和功能的提供者之间松散耦合的互连。ESB作为逻辑中间层的角色允许截获消息，并在消息在服务请求者和服务提供者之间流动时对消息进行处理。该处理称为中介。图3.服务虚拟化务必要了解ESB体系结构模式可以通过不同的方式物理地实现。在图1中，ESB作为集中的集线器出现，并且该体系结构模式在许多解决方案中的物理实现事实上都是一个物理集线器。图3试图说明该体系结构模式可以具有不同的物理实现；例如，可以分散ESB，以便能够在服务请求者环境、服务提供者环境、集中的集线器环境（或者是那些实现的任何组合）中物理地通过中介进行传递。（在本系列的后续各期中，您将了解有关各种ESB拓扑的更多详细信息。）对各种类型的中介的支持使ESB可以满足支持关注事项分离的两个核心原则：服务虚拟化和面向方面的连接。第一个原则（服务虚拟化）指的是ESB在服务交互期间虚拟化以下内容的能力：协议和模式。交互参与者不需要使用相同的通信协议或交互模式。例如，某个请求者可能需要通过某种固有的同步协议进行交互，而服务提供者可能需要使用某种固有的单向协议进行交互，并使用两个相互关联的交互。ESB提供所需的转换以屏蔽协议和模式切换。接口。服务请求者和提供者不需要就用于交互的接口达成一致。例如，请求者可以使用一种形式的消息来检索客户信息，提供者可以使用另一种形式的消息。ESB提供所需的转换以协调差异。身份。交互中的参与者不需要知道交互中的其他参与者的身份（例如，地址）。例如，某个请求可能由不同物理位置的多个潜在提供者中的任何一个来满足，而服务请求者不需要意识到这一点。实际提供者仅对ESB可知，并且事实上可以更改而不影响请求者。ESB提供所需的路由以隐藏身份。第二个核心原则是面向方面的连接。面向服务的解决方案包括多个横切方面(cross-cuttingaspect)，例如安全性、管理、日志记录和审核。ESB可以代表服务请求者和提供者实现或执行横切方面，从而从请求者和提供者的关注事项中消除此类方面。面向方面的连接和更熟悉的面向方面的编程概念之间的相似性是非常明白的，并且在不同的上下文中提供了同样的价值。通过中介应用这些核心原则使得ESB可以影响交互中的服务质量。可以通过抽象让参与者不必了解交互的某些方面。例如，可以考虑审核：如果某个解决方案需要审核，ESB可以向交互中添加审核而不影响参与者。类似地，ESB可以通过使用自己的虚拟化功能来重试失败的交互，从而添加或增强服务级别协议，或者在更复杂的情况下，ESB可以将请求者的要求与提供者的功能进行匹配。不过存在相关的限制，因为交互的某些方面是无法抽象的。例如，如果ESB无法可靠地与参与者之一进行交互，则ESB就无法提供可靠的端到端交互。ESB核心原则示例某银行有一个必须检查信用记录的现有应用程序。该银行正在自动化其信用检查流程，并将使用一个业务合作伙伴的信贷审批Web服务。该现有的应用程序使用一个通过MQ的文本消息和一个相关联的响应，从而与当前信用检查系统进行交互。考虑该银行的ESB中的一个能够完成以下任务的中介：侦听MQ队列并将相关联的响应发送到MQ队列将现有应用程序中的文本消息转换为与合作伙伴的信贷审批模式兼容的消息，并执行反向转换。与安全基础设施交互以插入必要的安全信息调用业务合作伙伴的Web服务并留下已做的审核跟踪作为该银行的面向服务的体系结构的一部分实现ESB可以提供以下好处：现有的应用程序逻辑不会更改。如果ESB可以使用该应用程序原先使用的相同MQ队列，则配置也不需要更改。审核跟踪支持与合作伙伴之间的业务协议的协调。如果业务合作伙伴的服务不满足其服务级别协议，该银行可以通过在ESB中修改路由和转换以切换到新的服务提供者，而不会干扰使用该服务的客户端应用程序。逻辑模型的以ESB为中心的视图本文前面一个部分已将ESB在整个SOAFoundation范围中进行了定位（请参见图1和图2），并且主要以从外到内的角度研究ESB。下面将以从内到外的角度研究ESB。图4描绘了ESB与该参考体系结构逻辑模型的其他部分之间的许多重要关系。图4.逻辑模型的以ESB为中心的视图应用程序逻辑与集成逻辑的比较请注意，有几个SOAFoundation部分通过ESB互连，即交互、流程、信息、合作伙伴、业务应用程序和访问服务。这些部分已分组到单个标签为应用程序服务的类别中，该类别定位在ESB外面。分组为应用程序服务的Foundation部分用于实现不同形式的服务请求者和服务提供者。这是解决方案中的应用程序或业务逻辑，旨在实现特定于领域的业务目标。ESB实现解决方案中的连接或集成逻辑。此逻辑执行服务虚拟化和面向方面的连接，旨在实现应用程序服务之间随需应变的互连。在理想的面向服务的解决方案中，应用程序和业务逻辑与连接和集成逻辑之间的分离是“彻底的”，意味着服务请求者和服务提供者（应用程序服务）不包含连接或集成逻辑，并且ESB不包含应用程序或业务逻辑。只有通过架构这种彻底的分离，企业才能实现从SOA中寻求的灵活性、敏捷性和重用。有时很难在应用程序和业务逻辑与连接和集成逻辑之间进行区分。不存在严格的指导原则，事实上，具体的选择可能取决于企业的性质甚至是企业中的特定情况。一个通常有效的指导原则是利用语义和语法之间的区别。应用程序和业务逻辑创建、读取、更新或删除与实现业务目标相关联的语义。相反，连接和集成逻辑仅修改与实现必要的互连相关联的语法。一个相关的指导原则是利用交互特征。应用程序和业务逻辑是主动的，因为此逻辑创建或使用服务交互中使用的消息（请求和响应）；连接和集成逻辑是被动的，因此此逻辑只是对业务逻辑生成的消息做出反应，并且只是将消息从一个参与者移动到另一个参与者。应用程序/业务逻辑与连接/集成逻辑示例某银行可能有一个必须使用Web服务调用来检查信用记录的新应用程序。该银行希望使用两个信用报告服务之一作为两个业务合作伙伴的任何一个的Web服务，其中任何一个服务都无法确切匹配该银行的信用记录数据模型。该银行希望使用第一个业务合作伙伴的服务，除非该服务不可用。新的应用程序确定何时调用信用记录服务，并使用该银行的数据模型来调用该服务。此示例中的应用程序/业务逻辑由该新应用程序加上两个信用报告服务组成。此示例中的连接和集成逻辑由必需的处理组成，以将信用记录模型转换为适合于所调用的信用记录服务和故障转移的模型，以便在第一个服务失败时调用第二个业务合作伙伴；此逻辑作为中介嵌入在ESB中。管理服务请注意，面向服务的解决方案的一些重要功能（尤其是作为任何面向服务的解决方案组成部分的管理服务）也定位在ESB之外。这是因为诸如安全性和IT管理等功能具有解决方案级别的范围，并且需要解决方案的组成部分之间进行超出ESB范围的协调和合作。请注意，ESB并不提供应用程序服务和管理服务之间的连接，并且可以在没有ESB参与的情况下保护和管理解决方案。ESB在保护和管理解决方案方面发挥显式的主动作用是可能的，并且经常是可取的。在此情况下，安全和管理策略由ESB之外的策略管理点设定，并且适合于将ESB视为此类策略的策略执行点。因此，虽然策略是使用与ESB没有直接关系的管理和安全服务来设定的，但是ESB帮助执行该策略。结果，管理服务的特征就是松散耦合到ESB。服务注册中心服务注册中心（有时称为服务存储库或服务注册中心/存储库）包含并管理元数据，这些元数据描述面向服务的解决方案中的服务。元数据的示例包括接口描述、端点地址和涵盖服务级别协议、安全关系等的策略。注册中心包含的服务元数据（因此也包括注册中心本身）在面向服务的解决方案中具有非常广的范围，并跨越治理、开发和管理以及运行时。图2特别说明了注册中心在面向服务的解决方案中的重要性质；图中将注册中心描绘为一个操作系统，此操作系统跨越从集成到治理的垂直层堆栈。图1和图4表明ESB需要服务元数据以执行服务虚拟化和面向方面的连接。ESB可以仅使用开发期间提供的静态元数据来提供价值。然而，要实现完全自动的服务虚拟化和面向方面的连接，ESB需要在运行时访问服务注册中心，以获得必要的服务元数据来控制解决方案的动态行为。因此，我们断言服务注册中心是配置和控制ESB行为的首选方法；可以说服务注册中心是控制ESB行为的策略的策略管理点，并且ESB是服务注册中心中与连接相关的策略的策略执行点。因此，我们可以认为服务注册中心的特点是与ESB紧密耦合。服务注册中心的使用示例某银行可能有一个必须使用Web服务调用来检查信用记录的新应用程序。该银行希望使用当前业务合作伙伴作为Web服务提供的信贷审批服务，但是希望在必须使用另一个业务合作伙伴提供的服务时最大限度减少任何中断。在最简单的情况下，到任何潜在业务合作伙伴的接口是同一个接口，该银行使用一个ESB中介，此中介从注册中心查询端点地址以便在交互中使用。开发服务图4中的开发服务提供了可用于开发和管理ESB的工具。开发人员希望使用工具来开发在ESB中运行的连接和集成逻辑，或者中介。类似地，管理员可以在部署后使用工具来管理ESB。理想情况下，此类工具使用服务注册中心。例如，开发工具可能允许中介开发人员使用注册中心查找某个交互所需