ESB: Mule胡思乱想之连接

摘要：本文将对ESB和Mule在连接方面做了一些思考和小结。
关键字：ESB,Mule,UMO,端点，服务消费者，服务提供者，入站，出站。


   首先考虑一个最简单的例子：只有一个入口和一个出口。只涉及到一个服务提供者和服务消费者。服务提供者只提供webservice协议进行访问。消费者只能通过http协议。那么两者如何通信呢。消费者没法直接访问提供者，那么消费者就访问ESB了。ESB就提供了一个虚拟的基于http协议的端点。然后ESB就在另外一端以webservice协议访问提供者。就这么简单。

   但是在这里必须弄清楚的是：从服务提供者的视角来看，只有一种方式连接到ESB。从消费者的视角来看，可以以多种方式访问ESB。从ESB的视角来看，有多种方式访问服务提供者，但是对于一个特定的服务提供者来说访问方式是一定的。

   好了。这里定义了两个端点（服务地址+访问协议）。一个是虚拟的ESB为消费者提供的访问端点。一个是真实的可以为ESB所能访问到的服务端点。那么在这两个端点之间又有点什么东西呢？应该定义什么东西来连接着两点呢？Mule定义了一个叫UMO的组件。然后将两个端点附在了UMO上面。UMO本来就是一个虚的概念，它可以是POJO，也可以什么都不是。Mule需要一个载体来完成两个端口的连接，这个就是UMO。这样Mule就可以将其他的ESB概念：数据格式的转换，路由，监控和日志往UMO上面加了。这么一路下来不就是一个管道的概念了吗？服务消费者-->入站端口-->数据格式转换-->路由-->UMO-->路由-->数据转换-->出站端口-->服务提供者。

   到这里，前面一段是根据正常的思路一步步走来。后面我就开始胡思乱想了，也不知道原作者是不是这么想的。

   UMO之虚与实：当出站端口连接的是一个真实的访问地址，这个UMO就是实的；反之则是虚的。UMO也可以同时有实有虚。例如下图，UMO1就有虚有实，UMO2就是一个实的。为什么会这样呢？实与虚其实是针对是否有业务服务来说的。有则是实的，没有则是虚的。根据ESB是连接，管理，路由的这么一个原则。实的端口就实现了连接的这么一个功能。而需的其实起到了一个路由的作用。那么一个服务请求完全有可能经过N个虚的UMO才到达服务提供者。ESB不应该有真实的业务服务。那么UMO就是一个抽象的东西，它不实现业务逻辑。

画完这幅图，我怎么觉得它像一个树形结构啊。UMO是枝，Service Provider 就是叶啊。

   端点之主动与被动：一说到主动，被动，我就想到男的应该主动，女的应该是被动的。那么ESB应该是主动还是被动呢？两者都有，那ESB岂不是不男不女。扯远了。首先ESB作为服务提供者的代理，它应该提供代理服务被动让各种消费者访问；其次，ESB作为服务的联系人应该主动地调用真实的服务。那么像前面的例子，入站就是被动服务啦，有请求来我就进行处理，请求通过继续往前走，不通过就打回去。出站就是主动服务了，调用真实的业务服务组件。那么Mule是如何处理的呢？Mule也定义了入站和出站。Mule的出站没什么好说的，肯定是主动出击了，访问真实的服务或是下一个UMO节点。可是Mule的入站除了被动，还可以主动。先说被动，例如http,soap,servlet,tcp,vm等协议在入站时就是被动的，有请求来我就处理。其实现就是把MessageReciever设计成一个监听服务，不断监听端口是否有请求进来。这个太好理解了。可是对于file,ftp,jdbc协议，竟然可以是主动出击，而不是被动等待。奇怪了，what happen？仔细想了想，问题出在协议上面，http等协议是一种请求/响应的模式。而file等协议是一种实体操作模式，例如读写文件系统，读写数据库。所有这种模式在入站端只能是主动出击了，从文件系统和数据库自动抓取数据。

参考：
1. Mule开源项目
2. ddj-Defining the ESB by Eric J. Bruno
3. 《SOA原理，方法，实践》
4. 网络文章，blog。