esb 服务编排

介绍

如今，企业服务总线确实是有用的解决方案，它结合了一系列工具，可以解决应用程序和服务集成领域中的实际问题。 但是，它们给工具箱带来了轻微的不便，给工具箱用户带来了不便，后者知道解决问题的方法必须在工具箱中，但出于他的原因，他不知道是哪一种！

本文的目的是帮助ESB用户在遇到最复杂，最多样化的ESB概念（路由和编排）时，根据他们的需求选择正确的答案。 我们将不使用抽象理论，而是使用符合OW2 PEtALS JBI的ESB [1]在简单，真实的示例中进行工作和推理，以填补低级路由与全局业务服务编排之间的空白。 换句话说：我们将尝试揭示路由和业务流程的不同层是如何建立的。

从企业服务总线到路由问题

ESB具有很多应用领域，包括实施信息系统范围的面向服务的体系结构（SOA）。 但它们的最低目的都是为了简化应用程序和服务的集成-也就是说，让一个应用程序或服务调用另一个。 这种非常简单且通用的工作具有各种附加级别的复杂性：

• “路由”，是指呼叫源于一个或多个目标服务之间进行选择的一个或多个源服务时；
• 当服务在另一个协议上公开时，“协议桥”属于其他服务器甚至其他信息系统；
• “转换”，即服务消息的数据格式不同时–这是规则而不是例外。

这三个：路由，协议，转换具有一系列紧密的同级关系，但是仍然可以视为主要的ESB概念。 在本文中，我们将重点介绍第一个及其与Orchestration的紧密关系的关系。 作为简短的介绍，我们可以说路由从根本上说是低层的，在ESB核心附近或在ESB核心中，并且依赖于技术配置（例如服务部署描述符）来提供关于必须将消息发送到何处的技术决策。 编排可以看作是组合服务调用以创建更高级别，更有用的组合服务，但通常也具有确定的“业务级别”环，在这种情况下，是实现将业务特定服务组合在一起的业务级别流程的简写应用程序和信息系统。

路由与编排：“一个大小不能适合所有人”或“黑白”世界

那么，ESB如何满足编排需求呢？ 使用中间件解决方案随附的编排引擎似乎很合逻辑。 但是，这对于一个复杂的问题来说太简单了。 让我们考虑以下示例。

显示项目清单

“ ItemManager”应用程序旨在通过创建，更新，删除等操作来管理项目。 此应用程序连接到“ ItemManagementListener”服务，该服务在更新项目时发布通知。

另一个应用程序“ HammerMonitor”应用程序是一种监视工具，它显示有关项目更新的信息，尤其是有关锤子的信息。 此应用程序通过接收这些通知的“显示”操作公开“ HammerMonitor”服务。

两种服务都在ESB上公开。 我们想要的是让HammerMonitor显示ItemManagement应用程序已知的锤子。

为了将ItemManagementService连接到HammerMonitorService，我们需要配置ESB连接器（也称为“绑定组件”）。 一个连接器链接到ItemManager应用程序，另一个连接器链接到HammerMonitor应用程序。

此外，链接到HammerMonitor应用程序的连接器配置为在ESB内部公开其名称可以为“ hammerMonitorService”的端点。 因此，实现我们目标的一种简单方法是配置链接到ItemManager应用程序的连接器，以使其在ESB内部每次从ItemManager应用程序接收到消息时都调用端点“ hammerMonitorService”。

但是，就像在现实世界中一样，我们可以说两种服务都具有不同的数据格式。 这不是SOA的障碍，因为SOA定义了松散耦合的体系结构（即，服务使用者不必须符合服务提供者的定义）。

ItemManagement应用程序向ItemManagementListenerService提供以下消息：

<items>    <item type="Hammer" name="hammer1"/> </item>

并且ItemMonitorService具有使用以下格式的“显示”操作：

<hammers>    <hammer hammerName="hammer1"/> </hammers>

在这一点上，仅呼叫不再有效以链接两个服务。 必须先转换ItemManagement应用程序提供的数据。 这实际上是非常简单的本地编排需求，与业务级别无关。

解决此问题的第一种方法是使用通用的，众所周知的编排解决方案，例如完整的，外部部署的，支持BPEL的编排引擎[2]。 可以，但是在这种情况下，这类似于使用锤子（双关语）打开螺母：要么所有已转换的消息都必须通过单个中央远程编排引擎，就像过时的“集线器”集成体系结构，否则必须在每个节点上部署业务流程引擎–对于这个简单的问题，这显然太繁重了。

因此，似乎对编排需求没有一个单一的，全球性的，业务级别的答案是足够的：当总线提供的通用路由不够时，在路由和业务级别之间必须完成的“肮脏”工作又如何呢？主要的关注点还不是通过操纵SOA管理的业务服务来实现业务规则或流程，而仅仅是结合技术的“幕后”服务以使它们“完成工作”？

总线级别的特定开发方法：拦截器

解决技术路由和业务流程需求的最底层答案是增强ESB的内置功能。

在我们之前的示例中，一种避免发送消息的应用程序和接收消息的应用程序之间的数据一致性问题的直接方法是在连接器（即ESB的绑定组件）中添加一些逻辑。

例如，可以使用“拦截器”扩展PEtALS ESB提供的绑定组件。 拦截器是一段Java代码，它在消息发送到总线之前在“发送方”绑定组件中执行，或者在传递消息时在“接收器”组件中执行。

在我们的示例中，此代码可以调用XSL转换，以使ItemManagement消息格式适应HammerMonitor格式。

然而，这种方法是非常严格的，并且不广泛。 如果XSL转换是在“接收器”连接器（链接到HammerMonitor）中执行的，则假定所有接收到的消息都具有ItemMangement XML结构。 如果消息来自另一个应用程序，则消息可以具有不同的结构，在这种情况下，XSL转换可能会失败。

拦截器可以检查传入的消息结构，并根据消息选择一个XSL转换或另一个XSL转换，但仍然与发送者保持非常紧密的联系。 这种方法不遵守SOA的松散耦合概念。 而且，除了转换之外，任何其他需求都意味着在ESB引擎中开发另一组特定功能，这是ESB用户无法期望的，也不应该。

面向组件（“构建块”）的方法：EIP工具集

ESB通过提供集成组件来提供集成工具。 这些组件可以在消费者和服务提供商之间执行一系列小的，有用的，灵活的操作。 它们通常实现几种企业集成模式（由Gregor Hohpe [3]熟知），并且是ESB用户的瑞士刀。

与服务描述（WSDL和其他服务描述）无关，这些EIP组件仅执行很小的事情。 最著名的是：

• “管道”模式：单个事件触发一系列处理步骤，每个处理步骤执行特定的功能。 EIP组件对呼叫进行排序。
• “基于内容的路由器”模式：EIP组件根据消息中包含的数据检查消息内容，并将消息路由到其他通道。
• “消息调度程序”模式：EIP组件将消息发送到服务提供商列表（多点）
• “分散收集”模式：EIP组件将请求消息路由到许多服务提供商。 然后将所有响应汇总到一个响应消息中

所有EIP组件操作的知识都使开发人员可以将业务应用程序（消费者和服务提供商）与几种“集成模式块”结合在一起。 最终结果是复合集成。 集成的每一块都是服务。

当然，为了设计这种复合集成，专用的图形IDE是最重要的，因为它除了易于使用之外，还带来了所有模块配置的集中视图。 例如，以下示例是由PEtALS ESB集成工具设计的。

管道

管道模式用于将传入消息“管道”到几个服务。 该消息被发送到第一个，其响应被发送到第二个，其响应本身被发送到第三个，依此类推。

消费者与服务提供商之间的适应

我们前面描述的ItemManagement用例可以使用这种装配，转换组件和“管道”砖进行设计。

管理服务版本演变

可以通过以下方式使用相同的行为来管理服务版本的演变。 使用者始终将相同的消息结构发送到“管道”砖，它是真实服务的代理。 当服务签名更改时，“管道”砖首先将消费者消息发送到XSL转换（以使消费者消息适应新的服务格式），然后将其发送到服务的新版本。 消费者并没有改变。

基于内容的路由

我们已经看到了如何将多个服务组合为一个服务。 但是动态过程方面没有解决。 路由挑战又来了：如何在众多服务中调用一项？

如何在多个服务之间切换到一个服务的呼叫？ 好吧，路由器砖可能会执行一些测试，以将请求切换到一个版本或另一个版本。

例如，ItemManagementListener可以将锤子和锯子项目的通知发送到“基于内容的路由”组件。 该组件测试消息中项目的名称，并将其发送到正确的监视服务（HammerMonitorService或SawMonitorService）。 由于每个服务定义了不同的格式，因此在将消息发送到正确的服务之前必须执行两次不同的转换。 因此，我们将“路由”砖与“管道”砖和“转换”砖组成。

调度员

另一个集成需求可能是将请求发送到多个服务（多点通信）。 例如，当将商品订单从前端应用程序发送到订购系统时，还可以将电子邮件发送给客户以进行确认。 例如，邮件被发送到订购服务和SMTP服务。

我们可以想象，从ItemManagement应用程序发送通知的ItemManangementListener服务必须将通知发布到HammerMonitor，SawMonitor和全局监视工具（接收所有通知）。

可以将“ dispatcher”集成模块添加到先前的复合集成中，以将消息发送到“ routing”模块和全局监视服务。

基于DSL的方法：灯光编排器

模式结束的地方，灯光编排器开始

企业集成模式是帮助构建路由和业务流程解决方案的重要概念，而EIP组件是允许针对这些问题实际设计解决方案的出色工具。 但是，在复杂的集成情况下，复合组装方法容易导致过于分散和过度设计的配置。 而且，像所有模式一样，EI模式数量有限，而现实世界充满了意想不到的情况，需要更灵活的解决方案。

答案是使用专用于轻业务流程的DSL（特定于域的语言），这是PEtALS中的“轻业务流程器”或“企业集成流程”组件提供的。

什么时候是使用此类组件的正确时间？ 这取决于很多事情，包括开发实践，但是这里有一些提示：

• 正如我们刚才所说，很难想象仅使用简单的“按书”模式的解决方案，
• 当“路由”和多路复用模式（例如前面所述的模式）变得司空见惯（这也可能暗示使用规则引擎组件）时，
• 当基于EIP的系统中有许多嵌入式“砖”层时，
• 在一个位置解决问题时最好地了解和维护业务流程子系统，而不是将其分散在多个EIP砖中，尽管它们很简单
• 当需要EIP组件不支持的稀有EI模式（全动态路由，返回地址，Content Enricher，Normalizer等）时

EIOrchestration用例：复杂的动态路由

为了展示EIOrchestration组件，让我们集中讨论系统的可扩展性。

我们已经了解了如何在最初只能处理锤子的系统中添加特定于锯的监视功能。 我们可以用相同的方式添加其他特定于工具的功能。 但是，这每次我们要添加其他工具类型时都需要再次重新配置它们。 那么，如果我们希望使用总线的人员能够添加自己的工具类型和特定的监视功能，该怎么办？

示例：我们的客户希望能够动态地为Screwdriver类型的工具添加一个ScrewdriverMonitorService，并为Drillers添加DrillerMonitorService，依此类推。

我们可以告诉他们在每条消息中提及必须将其发送到的特定于工具的监视服务的名称，并为我们的系统添加动态路由功能。

示例：我们增强了ItemManagement应用程序，以便它向ItemManagementListenerService提供以下消息正文：

<items>    <item type="Screwdriver" name="screwdriver1"          customMonitorService="ScrewdriverMonitorService"/> </item>

其中customMonitorService是客户可以通过ItemManagement应用程序提供的附加数据字段。

在ESB中，可以通过根据“ customMonitorService”属性动态选择其收件人服务来路由此类消息。 例如，可以使用EI Orchestration组件在PEtALS中使用其“ get-calls-by-xpath”功能来完成此操作：

<eip:get-calls-by-xpath base="/items/item" service="@customMonitorService"       operation="'display'"/>

在我们的示例中，它将使用上一条消息调用ScrewdriverMonitorService。

适用于PEtALS的完整EIOrchestration示例

我们在一开始就说过，PEtALS EIOrchestration组件可以很好地处理流程复杂性。 因此，这里有一个示例，它以单一配置收集了我们在本文中看到的所有内容：管道（“ eip：chain”元素）和转换，基于简单内容的简单路由（“ eip：choose”元素）以及最后的动态路由（“ eip：get-calls-by-xpath“元素），同时仍很易读：

<eip:eip>    <eip:chain>       <eip:choose>          <eip:when test="/items/item[0]/@type = 'Hammer'">             <eip:call service="ItemToHammerService" operation="transform"/>             <eip:call service="HammerMonitorService" operation="display"/>          </eip:when>          <eip:when test="/items/item[0]/@type = 'Saw'">             <eip:call service="ItemToSawService" operation="transform"/>             <eip:call service="SawMonitorService" operation="display"/>          </eip:when>          <eip:otherwise>             <eip:get-calls-by-xpath base="/items/item"                   service="@customMonitorService" operation="'display'"/>          </eip:otherwise>       </eip:choose>    </eip:chain> </eip:eip>

桥接业务流程管理概念

那么成熟的业务级编排又如何呢？

考虑集成的另一种方法是自上而下的方法，其中定义了企业业务流程。 通过这种方法，业务流程将驱动业务服务的定义。 因此，需要在现有应用程序提供的服务与业务流程要协调的服务之间建立桥梁。 这样的桥梁体现在企业信息系统内所有托管的业务级服务的集合中，即其SOA（面向服务的体系结构），它既充当总线上较低级别的技术服务的保护层，又充当服务层的保护层。实际的业务流程。

SOA世界中执行流程的标准方法是使用BPEL引擎[2]。 它可以调用多个服务并在流和XML文档上执行一些业务逻辑，同时还能够处理数据映射问题。 在这种方法中，业务服务定义是业务流程的关键：没有所有服务的定义（通常是WSDL），就无法进行BPEL业务流程，以确保更清洁（但成本更高）的服务组合。

Adrien LOUIS撰写的文章“从现有服务构建SOA应用程序”中提供了在ESB中使用BPEL时业务流程设置的概述。

人为干预业务流程：工作流程

现在，如果在我们的工具监视示例中，在实际显示监视应用程序中的信息之前需要主管的批准，该怎么办？ 这将需要专业操作人员的手动干预。 这是业务流程管理的另一面：工作流，这些业务流程允许通过可能在业务门户中提供的图形用户界面或其他方式参与手动的人工操作（无论是手动业务任务还是手动监督）技术管理界面。

关键点在于，工作流遵循与基于状态的方法相反的范式，而不是像BPEL编排器这样的基于流的方法，这使它们更好地适应了长期存在的流程，而不受限于坐在编排服务之上。 因此，工作流服务器由“直的”编排器进行了有益的补充，尽管这意味着部署两个面向业务流程的服务器-诸如jBoss＆Bull的“ Process Virtual Machine”和Eclipse Java Workflow Tooling项目[5]等有趣的新计划解决了这一限制。

结论

在本文中，我们已经看到了几种将业务服务彼此连接的方式，从低级的服务（如定制路由）到高层的业务导向的方法（如工作流和业务流程）。 最重要的是，我们介绍了ESB集成商如何在组成本地技术服务方面具有非常普遍的中级需求，以及一系列“胶水”，“瑞士刀”之类的功能如何使他们只需“完成工作” 。

综上所述 ：

• 对于一系列简单的集成方案，例如两个异构应用程序之间的连接，通过ESB特定功能自定义路由，例如通过在与应用程序链接的连接器中添加XSL转换来修改消息数据格式，实际上是最简单的方法（拦截器方法）。
• 当需要一种将消息发送到正确的接收者的策略时，以及当必须对消息进行链接时，我们可以使用组装简单的，面向模式的集成模块来执行静态路由，并与转换链接（EIP方法）。
• 为了解决包括动态路由或复杂约束的复杂路由策略，可以使用轻编排组件来集中路由逻辑（LightOrchestrator方法）。
• 在全球业务级别上，值得很好地使用编排（例如基于WSDL的BPEL）进行编排，并使用工作流解决方案与人们进行交互，这是值得付出的努力。

翻译自: https://www.infoq.com/articles/louis-dutoo-esb-routing/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

esb 服务编排