Mule ESB

Mule ESB在众多开源的ESB中处于领先者的地位，MuleSoft公司也作为独角兽，2017年在纽交所上市。我们作为MuleSoft的合作伙伴也有幸参与其中，在六年多的时间里，我们使用Mule ESB实施，包括使用Mule ESB企业版实施，或者在社区版基础上扩展，使用Mule ESB社区版实施，帮助国内众多的企业成功上线SOA项目。 使用Mule ESB的过程中，体会到其快速的开发效率，以及优秀的架构设计。同时也深感国内这块资料非常稀少，所以计划使用8篇文章来写Mule ESB的基础课程系列。 EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB EnjoyingSoft之Mule ESB开发教程第二篇：Mule ESB基本概念 EnjoyingSoft之Mule ESB开发教程第三篇：Mule message structure - Mule message结构 EnjoyingSoft之Mule ESB开发教程第四篇：Mule Expression Language - MEL表达式 EnjoyingSoft之Mule ESB开发教程第五篇：控制消息的流向-数据路由 EnjoyingSoft之Mule ESB开发教程第六篇：Data Transform - 数据转换 EnjoyingSoft之Mule ESB开发教程第七篇：SOAP Web

本篇主要介绍在Mule ESB中控制消息的流向。控制消息的流向有很多不同的场景，数据的路由，数据的拆分和组合，数据的排序，数据的分发等。数据路由是ESB平台上最基本，也是最重要的功能之一，完整的ESB平台都会有相对应的功能。ESB基本的功能可分成消息路由，消息传输和消息转换等，后续几篇Mule ESB开发教程我们会陆续讲解这些功能。 Mule ESB同样具有很多的消息路由组件。作为开源ESB产品中很成熟的平台，Mule ESB的发展状态非常好，经过多年的发展，2017年在纽交所成功上市。Mule ESB拥有众多的企业案例，我们作为MuleSoft的重要合作伙伴，使用Mule ESB企业版开发实施，或者Mule ESB社区版开发实施，帮助国内众多的行业标杆客户成功上线企业集成项目。 Mule ESB的源代码托管在 GitHub 上，拥有非常详细的英文文档，Mule ESB的中文文档资料和开发教程却非常少，我们使用8篇文章来写基础Mule ESB中文开发教程，一起为开源软件做贡献。 EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB EnjoyingSoft之Mule ESB开发教程第二篇：Mule ESB基本概念 EnjoyingSoft之Mule ESB开发教程第三篇：Mule message structure - Mule message结构

No Arguments Entry Point Resolver是定位Component类中的无参数方法的.Entry Point Resolver默认会忽略掉继承自Object类的notify(),toString()等方法。配置No Arguments Entry Point Resolver的代码如下 <no-arguments-entry-point-resolver acceptVoidMethods="true" /> 如果想排除掉某些方法，可以使用exclude-entry-point标签，不过这种情况下默认对Object类的方法的忽略将会失效，需要添加<exclude-object-methods />节点 <no-arguments-entry-point-resolver acceptVoidMethods="true"> <exclude-entry-point method="xxxx" /> </no-arguments-entry-point-resolver> 如果想要在指定方法中进行匹配，可以使用include-entry-point标签 <no-arguments-entry-point-resolver acceptVoidMethods="true"> <include-entry-point method="xxxx" /> </no

Property Entry Point Resolver定义的entry point指向Mule流程中inbound property中某个指定的property设定的方法名(如果这个property没有在property entry point resolver中指定,将使用默认property名method，否则将使用entry point resolver定义的property名）。 例如，我们在自定义Component中定义方法PropertyEntryPointMethod public class TestComponent { private final Logger logger = LogManager.getLogger(TestComponent.class); public void PropertyEntryPointMethod(String message) { logger.info("PropertyEntryPointMethod's message is:" + message); } 再在Flow的Component标签下指定使用Property Entry Point Resolver <message-properties-transformer doc:name="Message Properties" scope=

前面介绍了6种Mule ESB提供的Entry Point Resolver，如果在实际应用中觉得这些Entry Point Resolver不能满足实际需要，可以自定义Entry Point Resolver。自定义的Entry Point Resolver类必须继承抽象类 org.mule.model.resolvers.AbstractEntryPointResolver 我们这里实现一个自定义Entry Point Resolver，根据用户传入的两个操作数和操作符参数，分别执行不同的计算方法，返回操作结果。 我们计算传入的参数是json格式 { "operand1":13, "operand2":40, "operator":"add" ｝ 我们首先定义一个新的Flow，命名为Caculate_Flow 入口的Http Listener节点仍使用8081端口，为了和前面的Flow区别，Path改为Calc 流程中的Byte Array to String Transformer是把Http请求的InputStream类型的Payload转换为String类型的Payload。Json Translate Transformer使用了我们自定义的Transformer类CalcTransformer，把json报文转换为Object数组 public class

Reflection Entry Point Resolver是根据Mule Message的Payload参数类型匹配entry point的。配置代码如下 <reflection-entry-point-resolver acceptVoidMethods="true" /> 如果存在多个符合条件的entry point,将会抛出异常信息 ReflectionEntryPointResolver: Found too many possible methods on object "entrypointresolvertest.TestComponent" that accept parameters "{class java.lang.String}" 这是因为我们在TestComponent中配置了不止一个参数类型为String的方法,因此会出现匹配多个entry point的异常。 public void MethodEntryPointMethod1(String message) { logger.info("MethodEntryPointMethod1's message is:" + message); ｝ public void MethodEntryPointMethod2(String message) { logger.info(

Method entry point resolver是比较常用的entry point resolver。它根据用户提供的方法名以及Mule Message的Payload类型来匹配entry point。它的使用方式如下: ​<method-entry-point-resolver> <include-entry-point method="MethodEntryPointMethod1"/> <include-entry-point method="MethodEntryPointMethod2"/> </method-entry-point-resolver> ​ 这里指定了两个方法名，Mule ESB在匹配entry point时会先查找匹配第一个方法名的方法，如果没有找到，再查找匹配第二个方法名的方法，只要找到一个匹配的方法，会直接执行这个方法获得结果，而不会匹配其他匹配的方法。例如，我们在TestComponent类中定义了两个方法: public void MethodEntryPointMethod1(String message) { logger.info("MethodEntryPointMethod1's message is:" + message); } public void MethodEntryPointMethod2(String

Callable Entry Point Resolver 定义的entry point指向实现了org.mule.api.lifecycle.Callable接口的Component类的onCall(MuleEventContext eventContext)方法，Mule ESB默认的Component Entry Point Resolver就是这类resolver。前面的异常日志输出时我们已经使用了这种Entry Point Resolver，这里不再赘述。如果用户Component想获取Mule Context对象或者Mule Message对象，可以使用这种entry point resolver。 Callable Entry Point Resolver的配置如下 <callable-entry-point-resolver/> 来源： oschina 链接： https://my.oschina.net/u/237688/blog/733414

前面的系列介绍了Mule ESB提供和用户自定义的Entry Point Resolver，如果我们在实际使用中需要用到多个Entry Point Resolver进行Entry Point 匹配时，我们需要使用Entry Point Resolver Set。 Mule ESB提供的Entry Point Resolver Set包含两种，一种是系统默认的Entry Point Resolver Set: Legacy Entry Point Resolver Set,它包含了实现标准逻辑的Entry Point Resolver,这些Resolver包括 Annotation Entry Point Resolver 这个Entry Point Resolver前面没有提到，它主要是用于解析带有@Service标签的Component类的方法，匹配的方法所有的参数都需要有Mule Expression Language注解，例如以下的方法 public Object method1(@XPath ("/foo/bar")String bar, @Payload Document doc, @InboundHeaders("name")String name) { ........ } 这个方法的所有参数就包含了MEL注解 @XPath , @Payload,

前面介绍Mule ESB使用的系列文章中我们使用了自定义的Java Transformer和Java Component，用于接收和处理Mule Message。然而我们使用的Transformer和Component都必须实现AbstractTransformer接口或者org.mule.api.lifecycle.Callable接口，这使得普通的POJO对象无法直接被Mule ESB流程引用，必须填写实现接口的代码。这样不仅增加了代码开发的工作量，而且进行单元测试时无法脱离Mule ESB Container进行，具有很大的局限性。 从Mule ESB 3开始，引入了entry point resolver机制，Mule Flow在引用自定义Component时，同时定义对应的entry point resolver, 使得在Component没有实现接口的前提下，Mule ESB可以准确匹配到Component对应方法，将Mule Message传送给这些方法处理。Mule ESB将这一策略称为entry-point resolution strategy(EPRS),下图显示了Mule ESB如何使用EPRS进行Mule Message传递(Mule in Action 第二版的6.1中原来有配图，不过它基于Mule ESB 3.3版本，已经不适用于当前Mule ESB