mule号称开源ESB的最好实现，研究mule也有段时间了， 在“浩如烟海”的xml配置中，保持清醒的头脑确实不容易。
作为学习笔记之一，记录一下一个mule简单应用的实现。

需求：给指定的email地址发送邮件.

一：基本实现：

1: 实现命令行输入发送email：
为了能在命令行接受输入， 需要配置一个输入输出连接器：

2：配置一个UMO，把输入的内容放入一个队列：

outbound节点的配置， 把输入的内容(String) 路由到一个叫“content”的queue中， 此queue为jvm中的内存队列。

3:配置一个UMO，实现发送email:

其中inbound的配置为contentUMO的outbound， contentUMO和EmailBridge这个两个UMO通过名称为“content”的queue连接起来， 实现通讯。EmailBridge接收到输入后， 会依次通过ContentToEmail， StringToMimeMessage两个transformer进行内容的转换。

BTW:为了在mule中使用smtp， 需要在xml的namespace中声明：

xmlns:smtps="http://www.mulesource.org/schema/mule/smtps/2.1"

mule有很多对于具体协议的transport实现，每一个transport的实现作为一个jar包存在(比如mule-transport-email-2.1.2.jar)， 在jar中的Meta-INF/spring.schemas文件中， 写明了xsd文件的对应关系， Meta-INF/sping.handers配置了相关命名空间的handle class,可以据此在mule的配置文件中声明命名空间.
完整的mule配置文件如下：

相关class如下：
自定义消息转换器：

自定义smtp连接器(smtp connector):

运行此程序， 根据提示， 在命令行输入：

二： 升级：增加一个component.

修改UMO:EmailBridge配置， 增加一个component：

注意到增加了一个component， 接受命令行的输入(String),产生一个EmailModel的对象.之后，这个EmailModel对象进入outbound,并经过
emailModelToString， StringToMimeMessag的处理， 最后发送出去.
其中emailModelToString是新添加的一个自定义transformer：

相关class如下：
EmailModel.java:

EmailComponent.java
需要说明的是：
mule默认采用方法参数类型匹配策略， 所以， 如果有String类型的输入， foo方法自动调用， 也可以详细指定调用哪个方法，比如以下配置明确指定调用component的foo方法：

三：继续升级：不满足于在命令行输入， 需要在浏览器输入， 也就是发布一个http接口。
修改contentUMO如下：

过http请求得到输入参数， 经过HttpRequestToString的转换， 放入“content” queue,为了和content中的数据格式匹配，在浏览器中按如下方式输入:
http://localhost:9999?email=lichunlei@mycompt.com.cn,hello
新增了一个class：
HttpRequestToString.java

继续在mule的xml汪洋中遨游。
向一个vm:queue发送map消息， mule根据map信息， 动态执行sql， 并返回数据.select 的查询mule默认返回map数据.

注意： 如果mule采用2.1， jdbc transport的namespase后缀为com， 而不是org， 如果写错，IDE不会提示，程序异常也很奇怪,让我折腾了一个下午:(
测试程序：

执行的sql为：

insert的执行类似，只需修改如下：

mule的jdbc transport功能过于简单,今天的需求是把ibatis集成进来， 作为一个service的component,以增强持久层功能.
mule可以直接引用spring的配置文件， 方法如下：

作为一个演示，我需要往一个vm:queue中写入消息，component(由spring bean充当)
得到消息， 并作为查询参数 从数据库查询数据并返回.
model定义如下：

mule中关于component的xsd很不友好， component的子项居然是一个序列， 次序不能颠倒.
现在的任务就是完成userDao 的构建.
首先给出dao的接口：

在spring配置文件中， 装配userDao：

ibatis的配置文件长大很标准，就不贴了。
写一个userDao的测试， 以确保dao正常工作：

Mule的消息路由

异步方式

异步方式是一种单向调用，调用者不需要获得响应。

如果只想将消息以“即发即弃（fire andforget）”的方式发送给一个服务，（并不需要给调用者返回响应），那么可使用异步消息类型。如果将入站端点的synchronous属性设置为false，它就不会给调用者返回响应。

请求-响应方式

请求-响应方式即请求方调用服务后，服务立即处理并返回响应结果，不需将消息再次传递。

在简单的Request-Response场景中，服务在一个同步的入口端点上接收请求，并处理该请求，然后将它作为回复发送给调用者。例如，如果用户在HTML表单中输入一个值，想转换该值并将其结果显示在同一个页面上，那么可以在该服务上简单地配置一个同步入站端点，由该服务完成数据转换。这种场景并不需要使用出站端点。这就是request-response消息类型。

同步

如果为了进一步处理消息，需要将消息传递给第二个服务，那么需要在第一个服务上配置一个出站路由器将该消息传递给第二个服务。在第二个服务处理完消息后，第一个服务将它作为回复发送给调用者。值得注意的是将第一个服务设置为同步入口端点就意味着之后的所有服务都会以同步的方式处理该消息，所以无需在第二个服务上设置synchronous属性的值。这就是同步消息类型。

异步请求-响应方式

异步请求-响应方式即请求方调用服务后不需要立即获得返回结果，component将请求发送给其他外围系统处理（可能有多个），全部处理完毕后通过指定的异步应答Router返回给请求方。

在大多数复杂的场景中，可以使用request-response消息，并使用后端（back-end）流程调用其它的服务，并基于多个服务调用的结果异步地返回一个回复。你可以将入站端点的synchronous属性设置为false，因为异步回复路由器会处理该回复，除非你想给调用者发送响应。这就是异步request-response消息类型。

在下面的例子中，HTTP端点接收一个请求，并使用Multicast路由器将该请求广播到两个端点，再将这些结果以异步的方式发送到一个JMS端点。

将消息传递到另一个端点

当使用pass-through路由器时，如果想返回一个响应，必须将出站端点的synchronous属性设置为true。其它的路由器，比如chaining路由器并不需将出站端点的synchronous属性设置为true，该路由器总会在同步的场景中返回一个响应。因此，如果将消费发送给多个服务，可能会用chaining路由器代替pass-through路由器，因为chaining路由器中不需要将每个端点的synchronous设置为true。

过滤消息

使用过滤器可以控制服务处理哪些消息。选择性消费者路由器（Selective ConsumerRouter）用于入站端点，它可以控制服务处理哪些消息。过滤路由器（FilteringRouter）用于出站端点，可以控制哪些消息发送到下一个服务上。可以组合使用这些过滤器来控制消息流。

例如，如果只想处理不包含错误的消息，那么可以使用选择性消费者以确保只处理结果代码为success的消息。并使用Catch-all策略将其它的消息转发到另外端点上作为错误处理：

服务处理消息时，如果想通过指定的标准决定将消息发送到哪个端点，那么可以在出站端点上使用过滤路由器。在下面的示例中，将包含异常信息的消息发送到系统管理员的email邮箱，将包含特定字符串的消息发送到名为string.queue的队列，并使用forwardingcatch-all路由器接收余下的所有消息，并将它们发送到名为error.queue的死信队列：

与过滤路由器（filtering router）相似的路由器有转发路由器（forwardingrouter），它可以处理一些消息并可以选择性地将消息转发到其它路由器，还有wiretaprouter，这种路由器可以处理所有的消息，并将它们发送到端点上，同时也将消息的副本发送到另外一个端点。

将多个出站端点链接在一起

假设我们有一个验证服务，当消息没有通过验证时，想将该消息以及验证异常转发到另一个服务，并将消息和验证异常返回给调用者。那么可以使用链接路由器（chainingrouter），它是一个高速的、轻量级的可配置路由器，可用于将消息发送到端点，然后将该端点的输出结果发送到另一个端点。例如：

消息分解

消息分解器（message splitter）可用于将输出消息（outgoingmessage）分解成多个部分，再将他们分发到配置在路由器（router）上的不同端点。例如，在订单处理应用中，如果想将经消息分解后的不同部分分发给不同的服务去处理，那么可以使用下面的路由器：

列表消息分解器（List MessageSplitter）：接收一个对象列表，这些对象将被路由到不同的端点。例如：

表达式分解路由器（Expression SplitterRouter）：它与列表消息分解器相似，只是它是基于表达式分解消息，将消息分解成一个或者多个部分。例如：

为了提高性能也可以将消息分解成多个部分。轮叫（RoundRobin）消息分解器将消息分解成多个部分，并以轮叫（round-robin）的方式将它们发送到端点。Message ChunkingRouter将消息按固定长度分解成多个部分，并将它们路由到同一个端点。

消息分解之后，可以使用Message ChunkingAggregator重新将消息块聚合在一起。该聚合器（aggregator）通过关联ID（correlationID）来识别哪些消息块属于同一个消息，关联ID（correlation ID）在出站路由器（outbound router）上设置。

处理消息仅有一次

幂等接收器（IdempotentReceiver）通过核对输入消息的唯一消息ID来保证只有拥有唯一ID的消息才能被服务所接收。消息ID可以通过使用一个表达式从消息中产生，该表达式在idExpression属性中定义。#[message:id]是默认的表达式，也就是说如果要实现该功能，端点必须支持唯一性消息ID。在下面的例子中，唯一性ID是由消息ID和消息标头中标签的内容组合而成。所有的消息ID都被记录到一个简单的文本文件中，用于追踪哪些消息已经处理过。

通过组件绑定调用外部服务

除了使用消息路由器控制服务间的消息流之外，也可以通过组件绑定（Component Bindings）调用处理消息的外部服务（ExternalService）。

在这个方法中，可以将Mule的端点绑定到Java接口方法。该方法的优势在于，在组件仍在处理消息时，你可以使用外部服务，而无需使用Mule的API或者修改组件的代码。相反，只需要在XML配置文件中配置组件绑定，从而指定外部服务的端点。例如，在下面的绑定例子中，当sayHello方法被调用时，HelloInterface中的sayHello方法会调用外部的HelloWeb服务。