设计美好的服务器(4)--Mule ESB笔记

Overview

• Mule 
• Mule ESB笔记(花钱的年华) 
• Mule Training(MuleConf2007) 
• Exploring ESB Patterns with Mule(java.net) 
• Mule: A Case Study(TSS) 
• Evolutionary integration with ESBs(InfoQ)  

      Mule的运作能力非常强，商业的支持公司Mulesource.com，给大家贡献代码的MuleForge.org，2007年大会MuleConf2007，CXF的作者，SaleForces的CXO......

Features

• *企业服务总线的主要特性：*Pluggable的传输层，转换器，路由器三者是ESB的公共核心功能，同时Mule还是《Enterprise Intergration Patterns》与 SEDA (Staged Event-Driven Architecture)的遵循者。 
• *企业服务总线的其他特性：*事务、安全、异常管理 ，JMX管理架构。
• *Service Container：*Mule作为一个ESB，并不纯粹。UMO的角色很灵活，既可以是什么都不干的Bridge Componet成为真正的ESB，也可以是业务POJO，让Mule成为一个Service Container。 作为Container，有多通信协议，有SEDA，有JMX监控，也不错。
• *流程编排：*Mule and BPM, BPEL  ，  因为Mule的不纯粹的Bus，对于组合服务它并没有像BEA那样提供统一的流程编写语言，如果使用每个节点inBound-outBound-inBound的定义会看得很郁闷，与而jBPM结合未知。但它提供了使用UMO(POJO)在代码级进行服务编排的可能。
• *Cluster：*群集是它暂时还不支持的死穴，而BEA，ServiceMix都使用JMS的底层，用JMS群集来实现负载均衡，如果系统失效，JMS会回滚，将任务交给另一个消费者。而Mule使用vm queue来在每个节点间流动，也支持XA，也可以设置在shutdown时持久化到文件。Wiki中的计划 Cluster功能，有像BEA、ServiceMix那样跑JMS底层，有使用TerraCotta的实现计划。

架构

可以看出Mule的架构分三大块，传输层一块，POJO一块，还有一块运行时管理模块。

Transport Provider

Transport 是ESB最苦力的部分，Mule支持了WebService(Axis,XFire,CXF)/REST、Ejb/Rmi、Email、Jdbc、Tcp/Udp、Xmpp、VM、Ftp、File、Quartz，还有一些Transport如vfs、IBM MQ，藏在某个sandbox代码分支或者muleforge.org中。

名词：Provider由Message Receiver/Dispatcher，Connector，Adapter组成。
Message Receiver/Dispatcher负责具体收发，Connector负责与外系统的连接，Adapter负责转换协议特殊的数据格式，取得一些协议相关参数，比如http的Content-Length。Endpoint 定义了Transport+地址，如jms://topic:myTopic 

• Transport Guide 
• Writing Transports 

Filter、Router、Transformer

在mule里各种模式通常只是一个名词，要把《EIP》摆在手边，参考其描述与用例。

• Router
  动态的、宣告式的、基于内容的路由、基于规则的路由、BPEL、过滤、分解、聚合、重排
  http://mule.codehaus.org/display/MULE/Message+Routers 
• Filter
  http://mule.codehaus.org/display/MULE/Filters 
• Transformer 转换、包装、扩充、规范、压缩、加密、编码
  http://mule.codehaus.org/display/MULE/Transformers 

UMO Component

• Entrypoint Resolver，消息->UMO方法的解释与调度。
• 对象容器，基于Spring。
• UMO对象池，基于Apache Common  Pools。
• Interceptor ，默认有log和profile.  
• Writing UMO   

Misc

• Loan Broker示例讲解  Loan Broker是ESB最常用的示例，JavaZone2005上对Mule
• Mule 2 and Beyond 、Mule Roadmap Discussion 、Mule and Spring 、Mule and OSGi  Mule未来计划的会议PPT。
• Enterprise Service Bus HOWTO 

 

感觉应该提个Transport的jsr,
很多厂商都有一套Transport的接口.(如xFire, JbossESB等)

Router,Transformer也是.

这个基本上很难了，而且jsr也不是每个都混得这么如意，比如JCache，所有cache方案就没有哪个是把它放在眼里的。

mule我在1.3的时候非常关注，当时最郁闷的问题就是应用怎么集成（如app-muleA-muleB-app分布部署模式），因为当时还不提供真正意义上的Client API，应用必须把整个mule都包含进来，我在邮件列表中提了出来，我看到他们也很重视，但不知道现在怎样了，是否具有一个lightweight的client，我觉得还是比较重要的。

目前正在基于Mule做ESB产品，因为去年的时候做过一个ESB产品，并用其实施过几个项目，所以使用Mule做ESB也是清车熟路了。感觉还可以吧，向Apache的ServiceMix等等，都差不多，只不过MuleSource的文档不错，并且其现在由MuleSource维护了，服务要好多了。

甘肃万维?
很难相信开源的平台能在电信行业中被应用
做电信EAI系统吗？

这个太绝对了，虽然电信的确有钱没处花买了很多商业系统，但在无数业务管理系统里SSH之流满街跑就不用说了，MySQL/Tomcat/Linux是很多压力不大的系统的基础环境，像FreeRadius之类的在核心应用里也会用到，搜索引擎、规则引擎、工作流、报表系统，都可以看到开源的身影。

我们用mule在前年开发了一套短信平台，不过某些原因，这台平台没有商用。感觉mule在面向消息的系统中，还是不错的工具。我没有把它当ESB,就把它当作一个EAI工具用了。