Mule, AquaLogic ESB 学习阶段性总结（2009.9.21）

本文主要是介绍Mule, AquaLogic ESB 学习阶段性总结（2009.9.21），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

下面这段文字为转载：http://dragonetzhou.iteye.com/blog/171499

首先考虑一个最简单的例子：只有一个入口和一个出口。只涉及到一个服务提供者和服务消费者。服务提供者只提供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等协议是一种实体操作模式，例如读写文件系统，读写数据库。所有这种模式在入站端只能是主动出击了，从文件系统和数据库自动抓取数据。