Mule - 企业服务总线

<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>

一提到总线，一般学计算机专业的往往会联想到两样东西，一是网络拓扑上的总线结构，二是电脑主板上的总线。
和他们不同的是，企业服务总线是一种软件总线，但是他们都可以进行一定的类比。类比是快速学习最好的方法之一。

网络拓扑的总线由三个东西构成：网络设备（PC,服务器，交换机，路由器），端口（网卡－1个端口，路由器－n个端口），连接各个设备的网线，数据必须通过网卡端口传输到设备。
电脑主板上的总线也由三个东西构成。处理器（CPU,GPU），针脚（信号输入，输出的针脚），连接各个处理器的线路，同样在每一个时钟周期里，信号通过针脚进入处理器，再从别的针脚输出。

通过类比，可想而知，ESB软件上的总线必然也由吉祥三宝构成，在Mule里面，他们分别是UMO,End Point,数据的传输路线（当然这是无形的）。
UMO可以比喻成一个CPU，EndPoint就是这个CPU的针脚，数据从EndPoint（inbound）进入UMO，经过UMO的处理,从另一个针脚发送出（outbound），这样就完成了企业服务总线的一次最基本的操作。

Mule ESB最核心的概念:

1 UMO：从上面的描述可以看出，UMO就像一个CPU一样，它是业务应用的最基本单元。所有的业务逻辑都要写在UMO里面，例如收到一个请求发货请求的消息以后，我们首先检查库存是否足够，如果足够，那么生成一个发货单消息给仓库系统的接口。在这里面，检查存活和生成发货单是程序的业务逻辑，我们要开发一个进行该操作的UMO。
然后我们要定义该UMO的针脚，例如收到发货请求的接口，发出消息给仓库系统的接口。

2 Model：
Model包含了一组UMO，通常这一组UMO一起组成了一个应用。这就好比把一组小的CPU封装成一个大CPU来实现更复杂的功能。

3 End point:端点，就是我们前面说到的针脚，CPU只有通过针脚才能和外界交互，同样UMO必须通过End Point和别的系统交互。

Mule使用的关键，就是定义端点，这些端点就是系统交互的接口

<endpoint-identifiers></endpoint-identifiers>

<endpoint-identifier name="VoipBrokerRequests"></endpoint-identifier> value="vm://VoipBrokerRequests"/>

<endpoint-identifier name="ProxyService"></endpoint-identifier> value="axis:http://localhost:service/proxyService"/>

<endpoint-identifier name="BuyService"></endpoint-identifier> value="axis:http://localhost:service/buyService"/>

<endpoint-identifier name="ValidService"></endpoint-identifier> value="axis:http://localhost:service/validService"/>

<endpoint-identifier name="PurService"></endpoint-identifier> value="axis:http://localhost:service/purService"/>

一些其它的概念：

Translator：翻译器，翻译不同的消息协议，例如将Java对象翻译成SOAP协议

Normalizer: 规整器，规整器可以理解为一个协调员，它管理着多个翻译员，比如来了一个美国人，就把它分配给一个英语翻译员，来了一个德国人，就把它交给一个德语翻译员。在软件系统中，同一种消息可能有不同的格式，例如申请书，我们允许用户直接网上申报，或者客户端填写完毕后作为附件发送邮件。这些消息在规整器这里被归类，如果是直接申报的消息，交给一个翻译器处理，如果是邮件申报上来的，交给附件翻译器处理。

Recipient list：接收消息用户列表，用于一个消息你可能想发送到多个机构，例如你填写了一个申请表要同时发送给好几个部门审批，可以把这些部门都写在一个Recipient list中，系统会自动发送，就像短信的群发一样。

Aggregator：如果某一个事件需要等待好几个消息到齐后才进行处理，就可以使用它。例如我将申报表，资格表等分别发送给不同部门审核，等这几个部门审核结果都发送回来以后，我才可以统一处理他们。

====
Mule的UMO组件是POJO，所以初学者往往弄不清楚这些POJO的组件如何和整个ESB进行交互。

Entry Point 入口点
当UMO接收到一个事件之后，Mule会调用该UMO组件的入口点。Mule会根据事件的负载类型自动的选择一个方法来调用。
这意味着一个UMO组件可以有很多入口点。
事件的负载类型是由该组件接收事件的接收器中的入口转换器决定的，但有一些接收器例如soap接收器会自动管理类型映射，因此它就不需要转换器。
如果UMO实现了Mule默认的事件接口org.mule.umo.lifecycle.Callable，则该方法总是会被调用。

Event Flow 事件流

Mule有一些默认的规则来管理进出组件的事件流。

1. 当接收到事件时，Mule首先按照上面的描述调用入口点方法
2. 返回消息或称出口消息使用下面的方法获得 -
a. 如果调用的入口方法返回不是void, (Callable.onEvent() 返回一个Object) 直接使用该方法的返回对象。如果返回对象为null，该请求将不会进行进一步处理。
b. 如果调用的入口方法返回是void，则调用该方法时候传递的参数将被作为返回对象，此时我们假定这些参数的值被改变了。

3. 出口事件会根据组件的配置来自动的路由
a. 如果配置了出站路由，则调用该路由。
b. 如果只配置了唯一一个出口端点，则调用它。
c. 如果有多个出口端点，第一个会被调用。