一个ESB集成框架CodeHaus Mule

Mule 是一个基于ESB架构理念的消息平台。Mule 的核心是一个基于SEDA的服务容器，该容器管理被称为通用消息对象（Universal Message Objects /UMO）的服务对象，而这些对象都是POJO。所有UMO和其他应用之间的通信都是通过消息端点（message endpoint）来进行的。这些端点为众多的分立的技术，比如Jms, Smtp, Jdbc, Tcp, Http, Xmpp, file等等，提供了简单和一致的接口。

Mule 应用通常是由网络中的许多Mule 实例组成。每一个实例都是一个驻留一个或者多个UMO组件的轻量级容器。每一个UMO 组件都有一个或者多个通过它（们）发送和接收事件的端点。

容器通过UMO组件提供各种各样的服务，比如事务管理、事件转换，路由，事件关联、日志、审计和管理等等。Mule将对象构造从管理手段中分离出来，通常流行框架和IoC/DI 容器，如Spring, PicoContainer 或者 Plexus 可用这种管理手段来构建你的UMO 组件。

很多人认为， "Mule是一个Jms 实现"。实际上，Mule 不是一个Jms server，但是可以配置来使用任何你觉得非常漂亮的Jms server。Mule 的理念是，如果已经有了稳定和广泛接受的实现，就不会直接实现任何传输。例如，Mule 就重用了Axis 和 GLUE 的SOAP栈而不是重新实现一个。Mule 提供了一个一致的服务集来管理任何类型的连接的事件流、关联、事务、安全和审计。

 

下面是Mule Server 组件的简单图示：

 

Mule Manager

Mule Manager是Mule server 实例的中心(也称为一个节点户或者Mule Node)。其主要的角色是管理各种对象，比如Mule实例的连接器、端点和转换器。这些对象然后被用来控制进出你的服务组件的消息流，并且为Model 和它所管理的组件提供服务。

Model

model 是管理和执行组件的容器。它控制进出组件的消息流，管理线程、生命周期和缓充池。默认的MuleModel是基于SEDA的，它使用一个有效的基于事件的队列模型来获取的最大的性能和直通性。

UMO Components

UMO代表Universal Message Object；它是一个可以接收来自于任何地方的消息的对象。UMO 组件就是你的业务对象。它们是执行引入的事件之上的具体业务逻辑的组件。这些组件是标准的JavaBean，组件中并没有任何Mule特定的代码。 Mule 基于你的组件的配置处理所有进出组件的事件的路由和转换。

Endpoints

Endpoint是Mule的通信能力的基础。一个Endpoint定义了两个或者多个组建应用或者存储库之间的通信渠道。并且提供了一个强大的机制来允许你的对象在一个统一的方式上再多种协议之上进行交谈。端点可以通过消息过滤器、安全拦截器和事务信息进行配置来控制什么消息，在何时，以及怎样通过端点进行发送和接收。

External Applications

外部应用可以使任何应用，从应用服务器到遗留的传统应用，主机程序，或者C/S系统。基本上是任何可以产生和操纵数据的应用。因为Mule通过endpoints执行所有通信，UMO 组件并不打算在其中包含应用产生数据，以及应用主流，以及使用传输协议的部分。

 

关键特性

• 基于J2EE 1.4的企业消息总线（ Enterprise Service Bus (ESB)）和消息代理（broker）

• 可插入性连接，比如Jms (1.0.2b 和 1.1), vm (嵌入), jdbc, tcp, udp, multicast, http, servlet, smtp, pop3, file, xmpp等

• 支持任何传输之上的异步，同步和请求响应事件处理机制

• 支持Axis或者Glue的Web Service.

• 灵活的部署结构[Topologies]包括Client/Server, P2P, ESB 和Enterprise Service Network.

• 支持声明性和编程性事务，包括XA 支持

• 对事件的路由、传输和转换的断到端支持

• Spring 框架集成。可用作ESB 容器，而Mule c也可以很容易的嵌入到Spring 应用中。

• 使用基于SEDA处理模型的高度可伸缩的企业服务器

• 支持REST API 来提供技术独立和语言中立的基于web的对Mule 事件的访问

• 强大的基于EIP模式的事件路由机制

• 动态、声明性的，基于内容和基于规则的路由选项

• 非***式的方式。任何对象都可以通过ESB 容器管理

• 强大的应用集成框架

• 完整的可扩展的开发模式

何时使用

一般在这些情形下使用Mule -

• 集成两个或者多个需要互相通信的或者多个现有的系统.

• 需要完全和周围环境去耦合的应用，或者需要在系统中伸缩不止一个组件的系统

• 开发人员不知道未来是否会将其应用分发或者伸缩需求的单VM 应用。

项目地址：http://mule.codehaus.org/
转载。

现在流行webservice框架主要是Apache Axis2和Apache CXF。
Apache CXF是Codehaus XFire 的第二代产品，目前在不同框架中性能最佳，应该是开发者不错的选择，这与它本身的架构设计不无关系。相比其他框架，CXF具有几个突出的特性：支持JAX-WS、Spring集成、Aegi数据绑定、支持RESTful services、支持WS-*、Apache协议、代码实现简洁。Apache Axis2是Apache Axis1的第二代产品，架构上也非常不错，关键特性：支持各种规范、可插拔模块化设计、支持热部署等。与CXF相比性能也非常优异。
在服务端框架确定的场景下，最好是采用该框架生成客户端代码，这样配合性能可达到更佳。在实际的项目中，开发者在选择具体那个框架时，仍还需综合评估框架的开发组织、产品路线图、文档化程度、应用广泛度、与优异框架的集成度、灵活和扩展性等因素。
在具体项目的实现中，以前项目中用Axis2觉得不错，但是在不同的项目中CXF又支持的比较好，所以这个还要看项目了。各有优点吧！（找到适合自己的，才是最好的）