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"/>