基于DSL的方法：轻量级编配器

　　模式的终点即是轻量级编配器的起点

　　企业集成模式是帮助构架路由和编配解决方案的重要概念，而且EIP组件是能够切实设计这些问题的解决方案的绝妙工具。然而，在复杂的集成环境下，组合结构的方法极易导致过于分散和过度设计的配置。而且和许多模式一样，EI模式个数有限，而现实世界充满了需要更灵活解决方案的意外情况。

　　答案是使用轻量级、编配相关的DSL（领域特定语言），它就是PEtALS中提供的“轻量级编配器”或“企业集成编配”组件。

　　什么时候适合使用这种组件？这依赖于很多方面，包括开发实践，但是这里有些提示：

　　·就像我们刚刚说的，在仅仅使用正统、“常规”模式很难预见到一个解决方案的情况下，
　　·在经常需要前面描述的“路由”和多路模式（这也可能是一个需要使用规则引擎组件的信号）的情况下，
　　·当基于EIP的系统内部有很多内嵌的“单元”层次的时候，
　　·在一个编配子系统得到了很好地理解且在一个单一位置而不是分散在几个（虽然简单）EIP“单元”进行维护的时候，
　　·当需要一种罕见的EI模式且这个模式不被EIP组件支持的时候（全动态路由、返回地址、内容丰富器、规范化器……）

　　EIOrchestration用例：复杂动态路由

　　为了显出EIOrchestration组件的优点，让我们关注一下我们系统的扩展性。

　　我们已经知道了如何给一个最初只能处理锤子的系统增加一个监测锯子相关项目的特性。我们可以按同样的方式增加其他工具相关的功能。但是，这要求每当我们想要增加另一个工具类型时都对系统进行重新配置。那么，如果我们想让我们的总线使用者能够增加他们自己的工具类型和相关的监测功能呢？

　　例子：我们的客户想能动态增加针对螺丝起子类工具的ScrewdriverMonitorService，以及针对转孔机的DrillerMonitorService等等。

　　我们可以告诉他们：在每条消息中都给出它必须被发送给的工具相关的监测服务名，然后给系统增加动态路由功能。

　　例子：我们对ItemManagement进行了增强，它向ItemManagementListenerService提供以下消息体：

　　<items><item type="Screwdriver" 　　name="screwdriver1"customMonitorService="ScrewdriverMonitorService"/></item>其中增加了customMonitorService数据字段，它可能是客户通过ItemManagement应用提供的。

　　在ESB中，可以通过根据“customMonitorService”属性动态选择消息的接收者路由这种消息。例如，在PEtALS内，可以利用EI编配组件，使用它的“get-calls-by-xpath”特性办到：

　　<eip:get-calls-by-xpath base="/items/item" service="@customMonitorService"peration="’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" 　　peration="transform"/><eip:call service="HammerMonitorService" 　　peration="display"/></eip:when><eip:when test="/items/item[0]/@type = 　　’Saw’"><eip:call service="ItemToSawService" 　　peration="transform"/><eip:call service="SawMonitorService" 　　peration="display"/></eip:when><eip:otherwise><eip:get-calls-by-xpath 　　base="/items/item"service="@customMonitorService" 　　peration="’display’"/></eip:otherwise></eip:choose></eip:chain></eip:eip>

　　向上搭建沟通业务流程管理概念的桥梁

　　那功能齐全、业务级别的编配怎样？

　　另一种设计集成的方法是自顶向下的方式，其中会定义企业业务流程。在这种方法中，业务流程驱动了业务服务的定义。因而，在现有应用提供的服务和业务流程期望定义的编配之间需要建立桥梁。这种桥梁表现为企业信息系统内部所有受管理的业务级别服务集合，即它的SOA（面向服务架构），对于低级别、总线上的技术服务和实际业务流程来说，它都扮演了一个保护层的角色。

　　在SOA的世界中，执行流程的标准方式是使用一个BPEL引擎[2]。它可以调用几个服务并能在流程和XML文档中完成一些业务逻辑，同时还能够处理数据映射问题。在这种方式中，业务服务定义是编配的关键：哪怕缺少一个服务的定义（一般是WSDL）都会导致BPEL编配无法完成，因而你应该确保更清晰的（然而也是更贵的）服务组合。

　　假如要在ESB中使用BPEL，可以参考Adrien LOUIS书写的文章《使用现有服务构建SOA应用》，它提供了关于编配装置的一般性介绍[4]。

　　业务流程中的人类干预：工作流

　　现在，在我们的工具监测例子中，如果我们想要实现在管理员批准后方能在监测应用中实际显示信息，怎么办？这可能需要专门设置一个操作员来负责进行人工干预。这是业务流程管理的另一面：工作流，它是允许手工、人类操作干预的业务流程，要么因为手工业务任务，要么因为人工监督，通过业务门户或更技术性的管理界面提供的图形用户界面完成。

　　关键点在于，与象BPEL编配这样的基于流程的方法不同，工作流遵循的是相反的范式，基于状态的方法。这使得它们更适合长生命周期的流程，没有建构在编配服务之上的限制。因而，“正统的”编配是对工作流服务器的有益补充，通过部署两套面向业务流程的服务器的方法——部分地通过一些有趣的新项目得到了解决，如jBoss & Bull的“过程虚拟机”和Eclipse Java工作流工具项目[5]。

　　总结

　　在这篇文章中，我们已经了解了几种将业务服务彼此互联的方法，从使用如自定义路由这样的低级别方式，到使用如工作流和编配这样的面向业务的高级别方式。更为重要的是，我们已经展示了ESB集成器对组合本地、技术服务的中间级需求有多么普遍，以及一组“胶水”、“瑞士军刀” 式的特性是如何令它们简单地“把事情搞定”的。

　　总而言之：

　　·对于一些简单的集成场景来说（如两个异构应用间的互联），通过ESB相关特性来自定义路由，如通过在应用链接的连接器内增加一个XSL转换来改编数据格式，实际是最简单的方法（拦截器方式）。

　　·当需要某种策略来决定将消息发送给正确的接收者和链接消息操作的时候，我们一般可以使用装配简单、面向模式的集成单元来完成静态路由、链结转换（EIP方式）。

　　·要想解决复杂的路由策略，包括动态路由或复杂的鳞状结构，可使用一种轻量级编配组件来将路由逻辑集中起来（轻量级编配方式）。

　　·在全局，业务级别、良好管理、定义一致的面向业务的服务是值得使用编配进行组装的成果，如基于WSDL的BPEL。要和人类进行交互，可以使用工作流解决方案。

　　作者简介

　　Adrien Louis是EBM WebSourcing的PEtALS ESB首席架构师和SOA顾问，他拥有8年从事Java EE技术和信息系统集成经验。

　　Marc Dutoo是Open Wide的开源解决方案架构师，该公司是法国领先的开源门户集成商。他的兴趣包括SOA、BPM和内容管理。Marc还是Eclipse Java工作流工具项目的联合组长。