Mule介绍

Mule介绍

什么是Mule

Mule是一个基于Java的轻量级消息框架，它可以使我们快速、容易地将我们的应用连接起来，并且保证这些应用间可以交换数据。Mule使用了面向服务架构(SOA)，提供了对现有系统的简洁的集成方式。不管应用程序采用了什么技术，JMS、Web Service、JDBC、HTTP甚至其他的技术，Mule都可以准确无误地将它们集成到一起。

Mule框架具有很强的可扩展性，它允许我们开始只提供比较少的应用，然后再慢慢将更多的应用连接到其上。Mule透明地管理着应用和组件间的所有交互，不论这些应用和组件是处于同一台虚拟机上还是处在互联网上，不管他们底层使用了怎样的传输协议。

Mule是基于企业服务总线(ESB)的思想设计的。ESB的主要功能是扮演了在不同应用中传送数据的传输系统的角色让它们可以互相通信，不管这些应用是在内联网中还是跨越了互联网。现在市场上已经有几个商业应用的ESB产品，这些产品中许多只提供了有限的功能，或者是需要构件在已有的应用程序服务器或消息服务器之上，这就将你限制在了某个特定的提供商。Mule是一个中立的ESB产品，所以不同的提供商的产品都可以集成到其上，使用Mule，你不会被锁在某一个提供商的平台之上。

与竞争对手相比，Mule提供了很多优势，包括：

l Mule的服务组件可以是你想要的任意类型的。你可以很容易地把从POJO类到其他框架实现的组件的各种形式的应用集成起来。

l Mule和其ESB的模型提供了非常可观的组件重用。不同于其他框架，Mule可以让你不加修改地使用你现有的组件。这些组件不需要任何与Mule相关的代码，甚至编程接口(API)也不需要，就可以在Mule上运行。这样，业务逻辑和消息逻辑完全分离开来。

l 消息可以是从SOAP到二进制图像文件的任意类型。在设计上，Mule不会强制你使用任何设计约束条件，比如XML消息或者WSDL服务契约。

l Mule部署成多种拓扑结构，甚至可以不以ESB的方式进行部署。因为Mule是轻量级和嵌入式的框架，所以它可以很好地应对那些需要适应各种变化，并且按需求来增加和裁减功能的应用。在这种要求高可靠和可扩展性的系统中，Mule可以有效地减少部署时间，提高生产率。

 

MuleSource提供了管理工具，可以让你管理你的部署(Mule HQ)，监视流过系统的事务(Mule Satum)，控制系统的基础组件(Mule Galaxy)。在Mule管理部分将详细地介绍这些工具。

下一部分是理解消息框架，提供了对消息框架和Mule怎样在应用间进行数据交换的详细介绍。

理解消息框架

将你的应用联网的好处是一个应用可以发送数据给另一个应用。然而，许多应用并不具备从另一个应用读取或处理数据的能力。Mule提供了在多个应用间可以读取、转换和发送数据的消息框架来解决这一问题。简单说来，一个消息就是一包数据，这包数据可以在应用间通过一个特定的通道(或者队列)进行处理和发送。

最简单的情况下，当你把你的各种应用连接到Mule时，Mule会从一个应用中读取数据，为了数据可以被目标应用读取，Mule将其按照要求进行转换，然后把它发送给目标。这样，Mule就可以让你集成所有类型的应用，甚至那些不是为了做这个集成而构建的应用。

Mule是基于ESB思想的消息框架。ESB的主要功能是扮演了在不同应用中传送数据的传输系统的角色让它们可以互相通信，不管这些应用是在内联网中还是跨越了互联网。因此，系统的核心是在应用之间进行消息路由的消息总线。

Mule与传统ESB的一个不同之处在于，Mule仅仅是按照需要进行数据。传统的ESB上，你需要为连接到总线的每一个应用创建一个适配器，并将该应用的数据转换成单一的通用消息格式。这些适配器的开发和处理每个消息活动需要花费大量的时间和精力。Mule消除了对单一消息格式的要求。信息会被发送到任意的通信通道，比如HTTP或JMS，它只在沿途进行必要的转换。因此，相对于传统ESB，Mule提高了性能，减少了研发时间。

Mule的架构和术语使用了Gregor Hohpe和Bobby Woolf的合著Enterprise Integration Patterns:Building, and Deploying Messaging Solutions一书中描述的规范。对所有从事企业消息解决方案的人，这本书非常值得一读。

下一节理解Mule架构，更加详细地描述了Mule架构。

理解Mule架构

这一节描述了Mule架构的不同部分，它们是怎样处理消息的以及它们的数据。为了便于说明，这里使用了一个例子，这个实例中有一家公司，这家公司需要为顾客的订单开具发货清单，根据那些发货清单处理一些流程，并且将其送到商品库来完成订单。

1. 关于SOA

   内容略

2. 数据处理

当消息被从一个应用(比如发货清单的入口系统)发送后，Mule取出消息，将它发送到一个服务中，这个服务会使用具体的业务逻辑处理这条消息，比如检查用户和数据库的存货清单，然后将消息路由到正确的应用中，比如订单执行系统。Mule包含了许多独立的部分，来处理的路由消息。服务的关键部分是服务组件(service component)。服务组件会执行消息中的业务逻辑，比如读取发货清单，向其中添加用户数据库里的信息，并且将其转发到订单执行系统。

服务组件的一个重要特性是它不需要任何Mule相关的代码；它可以简单的是POJO、Spring Bean、Java Bean，也可以是包含了具体处理数据的业务逻辑的Web Service。Mule需要来管理这些服务组件，将其打包并发布为服务，并保证正确的消息进入的输出，这些都要借助于你为这些服务指定的配置文件来完成。

在你的应用中，有许多不同的服务来处理不同的业务逻辑，比如一个服务用于验证发货清单中的货品是否有库存，另一个则是使用订单历史记录来更新一个分离的用户数据库。所以你的被消息封装着的发货清单，需要在服务组件间流动，直到整个处理流程结束。

下一节，在服务组件间路由消息，描述了Mule是怎样路由消息的。

3. 在服务组件间路由消息

按照前面的规定，服务组件包含了处理消息中的数据的业务逻辑，但它并不包含怎样进行消息接收和发送的任何信息。为了保证服务组件接收到正确的消息，并且在处理后对它们进行合适的路由，你需要在配置Mule时，为组件指定入站路由(inbound router)和出站路由(outbound router)来封装服务。

入站路由指定了一个服务组件要处理哪些消息，它可以过滤进入的消息，聚合消息，以及在将消息发送到服务组件前对它们进行重新排序。例如，如果一个服务服务订阅了一个RSS，入站路由就必须要知道来自那个提供者的消息。

服务组件处理完消息后，出站路由指定向哪里发送这条消息。你可以定义多个入站和出站路由约束，甚至将多个路由链接起来处理消息，来保证服务组件准确地按照要求来接收和发送消息。

下一节从业务逻辑中分离消息，介绍了怎样将服务组件是怎样与消息层进行分离的。

4. 从业务逻辑中分离出消息

Mule从多优势之一是它可以处理通过多种协议发送的消息。例如，一个发货清单可能总是XML格式的，但它也可能在一种情况下通过HTTP协议送达，另一种情况却又通过JMS消息，这依赖于生成清单的服务。如果一个服务组件仅仅处理业务逻辑，与数据协同进行工作，那它怎样读懂消息发送来的各种各样的格式的呢？

答案是服务组件不知道怎样读懂这些消息，因为默认情况下，服务组件被完全与消息格式隔离了开来。首先只由一类与协议相关的传输组件沿途运送消息，然后在路由器将消息发送到服务组件之前，转换器会将消息的有效负载(例如发货清单)按照需要转换成服务组件可以读懂的格式生。例如，如果一个XML发货清单通过HTTP协议发送，这条消息沿途将由HTTP传输组件运送，路由器引导这条消息到要对其进行处理的服务组件上，转换器就会根据服务组件的需要沿途转换发货清单，比如将其由XML转换为Java对象。所有的对消息的传输，转换以及路由对服务组件来都是完全透明的。

转换器是交换数据的关键，因为它们保证了Mule可以将数据转换成另一个组件或应用可以理解的格式。更重要的是，数据仅在需要的时候才会转换。不同于将所有的消息转换成单一的通用消息格式，消息和它的数据仅在它们正在被发往的目标组件需要时，才会被转换。最后一点，你可以使用多种传输组件来处理不同的通道，比如发送了一条基于HTTP协议的消息，然后在它被客户数据服务组件处理后，使用JMS消息将其转发。

将业务逻辑与发送和转换消息进行解耦，给应用带来了巨大的灵活性，这主要反映在两方面，你可以创建自己需要的架构，并且使你不必关心消息到达的多种格式，而更加简单地定制自己的业务逻辑。必要情况下，我们的服务组件可以直接处理消息的原始数据，当然这不是必需的。

下一部分，将所有绑定在一起，描述了Mule怎样将所有的组件连接起来，并协调它们之间的流的。

5. 将所有组件绑定在一起

端点(endpoint)是连接起所有服务的关键，它是一个配置元素。你可以在入站路由和出站路由中指定端点，来告诉Mule使用哪个传输组件，将消息发送到哪里，以及哪一个消息组件应该接收它。端点的主要部分是地址(address)，它是使用统一资源标识符(URI)描述的，它指定了需要使用的传输组件，传输组件资源的定位和一些附加的参数。

举个例子，如果一个服务的入站路由指定了端点为http://myfirm.com/mule，HTTP传输组件就会把所有需要发送到这个URL的消息发送到这一服务。如果指定的是file://myserver/files/，那么文件传输组件就会监视这一目录，把所有这一目录中的新建文件发送到这一服务。在出站路由中指定端点指示了消息下一步去哪里——消息被发住的服务的入站路由需要与前一服务组件的出站路由相同，如下图所示。

一个服务可以使用不同的传输组件接收消息。你需要为一个服务要使用的每一种传输组件指定一个或多个的独立的端点。比如，如果你想让你的服务可以同时处理来自HTTP和JMS通道的消息，你应当需要在服务的入站路由里至少指定一个HTTP端点和至少一个JMS端点。Mule把这些端点登记在服务上，传输组件在运行期使用这些登记信息来配置自己，达到确定发送和接收消息的目的。

总的来说，Mule提供了简单、轻量级的方式来编写服务组件。这些服务组件可以处理数据，但它们不需要担心数据的发送和接收，消息的格式或者消息发送/接收使用的技术。尽管许多代理和集成技术提供了接入不同数据源的功能，但他们往往需要额外的代码来按照你想要的方式来获取消息，按照你指定的目的发送数据。Mule可以让你快速地开发服务组件，你可以使用简单的XML配置文件来修改它们的工作，而不需要写代码。

下一部分，理解逻辑数据流，讲述了一个详细的例子，来展示流过Mule各个部分的消息流。

理解逻辑数据流

前面的部分从概念的角度介绍了Mule的每个部分，现在，再使用发货清单的例子，来看一下数据流是怎样穿越Mule的各个部分的。完成这一过程的自始至终，Mule都是使用配置文件来确定要使用哪个服务组件、传输组件、路由器和转换器的。下面的图画出了这几步传输过程。

１． 用户在公司网站上发了一份订单，这一过程中，生成了一个XML格式的发货清单，并提交到了http://myfirm.com/orders。

２． HTTP传输组件接收到消息，用户数据服务入站端点被在http://myfirm.com/orders点工作，他在入站路由指定，消息必须包含一个Java对象，所以HTTP传输组件准备进行消息转换，并把消息转发到服务。

３． XML2Object转换器将XML发货清单转换成Java对象。

４． 传输组件将消息报发送到用户数据服务组件。

５． 用户数据服务组件查询主要的数据库，抽取与用户有关的附加数据，并将这些数据更新到发货清单中。

６． HTTP传输组件使用出站路由配置，确定了它现在必须将消息转发到http://myfirm/com/verify。

７． HTTP传输组件使用发货清单检查服务组件的入站路由配置接收消息，并将其转换到服务组件。

８． 服务组件使用仓库里的ID号更新了发货清单。仓库存有发货清单的所有有货的项目的信息。

９． 出站端点指定了一个JMS地址，所以JMS传输组件要将消息转送到定单执行应用中，该应用将使用JMS地址来取得订单。

现在你已经理解了Mule是怎样工作的，阅读下面的一节，将Mule集成到你的环境，你将学习到Mule所支持的部署选项和拓扑。

将Mule集成到你的环境

Mule是基于ESB架构思想的。ESB的消息骨架通常使用JMS实现，但是其他的消息服务器产品也可以使用，例如MSMQ、IBM WebSphere MQ(以前的版本叫MQSeries)，或TIBCO Rendezous。另外，使用Mule时，并没有对你的集成工作层的工作方式的严格限定，你可以连接到EJB，大型应用，消息，Web Service，socket，甚至文件系统，与他们都可以进行简单一致的交互。

Mule还支持ESB以外的其他拓扑结构，包括管道方式、对等网、C/S、Hub-and-Spoke等等。这些拓扑可以混合使用，并且配合连接到一个企业服务网络(enterprise service network)中，完成复杂企业消息和服务需求的模型组建，如下图所示。

与Mule集成时，你可以以比较少的应用开始，而后慢慢连接更多的应用上去。例如，一个Mule使用者开始集成了六个系统，三年后，他们把多达71个的系统使用Mule连接了起来。Mule允许你开始时，根据需求从简定制，而后进行方便地持续扩展。

你可以在你的网络上部署多个Mule实例，如下图所示。这种方式对故障转移和负载均衡都非常有用，如果一个Mule实例由于服务器停止失效了，其他的Mule实现可以处理它的消息。你可以向一个实例发送一部分消息，而向另一个实例发送另一部分来均衡负载。

你可以多种方式部署每个Mule实例，单点方式，嵌入Web容器(比如tomcat)，或者在应用程序服务器上。你可以使用私有的J2EE应用程序服务器，例如BEA WebLogic，IBM WebSphere，Oracle Application Server或者SunOne，也可以使用像Geronimo或JBoss这样的开源产品。

设计系统是一个艺术和科学并重的事情。系统必须正确的实现，并保证可扩展性。MuleSource专业的服务可以帮助你巩固你的架构，设计服务组件，或者所有的实现。联系MuleSource服务代理获取更多信息。

小结

Mule提供了可以使应用之间进行数据交换的消息框架。应用功能被包装成服务，这样的服务包含一个服务组件（用于处理数据的业务逻辑），路由器（使用端点来指定向哪里发送消息）和一些配置项。传输组件使用不同的通道在服务间传输消息，转换器沿途根据需要进行数据转换。

Mule不是现有的应用框架的替代产品。相反，Mule对一些开源的项目产生了影响，比如Apache CXF，Spring和ActiveMQ，填补了Java企业开发中对多平台中的多系统复杂交互这一需求的空白。Mule提供了以少量的工作就能完成将系统集成到一个强壮的，解耦合的环境中的方式，你甚至不用写代码，就能提供必需的系统间路由，传输以及转换消息的支持。

概述部分的主题是对Mule架构做一个介绍。现在阅读Getting Started部分可以获取如何下载、安装和开始使用Mule的信息。想知道根据你的角色你应当完成什么样的工作，赶快去阅读Quick Start吧。

配置Mule

配置概述

１． 配置文件

 

默认的，并且最常的Mule配置方式是通过XML文件。

使用命令行启动Mule

在命令行启动时配置文件由参数-config指定。

编程的方式启动Mule

编程启动Mule时，配置文件作为ConfigurationBuilder的参数提供。

 

２． Configuration Builders

３． 指定使用哪一个Configuration Builder

XML配置

正如上一节配置概述中介绍的，最常用的Mule配置方式是通过Spring XML配置文件完成，这些配置文件是要使用默认的Mule名字空间。

XML 语法

配置文件基于XML语法(schema)，在文件的最初指定。

必须要指定所有必须的语法文件，在创建配置文件时，这可能会比较耗时，但是导入语法提供了多种省时的好处：

l 在你使用的IDE中支持自动完成和详细的上下文帮助；

l 设计阶段的配置检查

l Typed properties

 

名字空间

每一个Mule模块或者传输组件有它自己的XML语法。当你导入一个语法文件时，它有它自己的名字空间。例如，下面的配置中就将mule-jms.xsd绑定到了jms名字空间。因此，所有以<jms: 起始的xml元素都要遵循mule-jms.xsd语法。

 

默认名字空间

通常下，会将Mule core语法设置为默认的名字空间。也就是说所有没有前缀的xml元素都遵循Mule core语法(mule.xsd)，设置默认名字空间语法的方法是，将Mule语法的URL指定给xmlns，去掉前面例子中的冒号和前缀，也就是使用xmlns替换掉xmlns:jms

 

Spring

尽管你的配置文件中出现了Mule相关的东西，但他们的确仅仅是附带了Mule相关扩展的Spring配置文件。这种方法可以让你在Mule配置中使用所有Spring提供的东西，比如beans，factory beans，resources loaders，EJBs，JNDI，AOP，甚至集成其他像Hivemind，jBPM，Gigaspaces，JBoss Rules等等此类软件。

使用标准的Spring元素，需要导入Spring名字空间：

 

属性占位符

你可以使用ant风格的属性占位符，例如：

 

正如这一节中描述的，这些占位符的值可以有很多种方法赋予

全局变量

你可以使用<global-property>元素来从Mule配置的内部设置一个占位符的值，比如在另一个Mule配置文件中：

 

属性文件

可以从文件中加载属性，你可以使用标准的Spring元素完成：<context:property-placeholder>

 

这里的smtp.properties文件的内容如下：

 

使用逗号来分隔需要加载的多个属性文件：

 

系统属性

占位符的值可以来自JDK系统，如果你从命令行启动Mule，你可以以如下方式指定这些属性：

 

或者在conf/wrapper.conf文件中编辑系统属性。

如果你使用编程的方式启动Mule，你可以用如下的方式指定属性：

 

环境变量

对于访问环境变量，没有标准的方式。这个链接里你可能会找到有用的信息。

配置一个Mule实例

基本配置

Mule配置文件可以表示成一个元素的描述树，不管什么形式的配置，最上层总包括以下的基本元素。

l 连接器(connectors)：所有的传输组件都没有默认的配置；

l 端点(endpoints)；提倡对端点进行全局定义，这样可以清楚地描述你的集成通道在什么位置；

l 转换器(transformers)：可能需要全局定义，然后在你的服务中进行引用；

l 过滤器(Filters)：同转换器。

l 模型(Models)；一个或多个模型，从逻辑上组成了你的服务。

 

 

 

 

高级配置

另外，你可能还需要某些高级的配置：

l 代理(Agents)：代理通常用于提供一些横向的服务，比如日志和管理；

l 通知(Notifications)：在有生命周期的事件上，通知某些事件；

l 安全管理(Security Manager)；

l 传输组件管理(Transaction Manager) ；

l 全局配置选项(Global Configuration Options)：不同种类的全局设置；

l 全局属性(Global Properties)：占位符的值。

 

配置选项

Mule上下文和Mule配置

所有的Mule配置都可以被一个对象：org.mule.api.config.MuleConfiguration访问。MuleConfiguration中的配置属性在Mule上下文(MuleContext)被创建时设置。在Mule启动后，这一对象是不可改变的，但它可以用如下方式进行访问：

 

配置变量

Mule配置变量可以用<configuration>标签进行配置。例如：

 

所有可用的变量如下表所示：

变量	类型	默认值	描述
defaultSynchronousEndpoint	属性	False	如果是true，对端点的连接就会持续等到响应。
defaultRemoteSync	属性	False	如果是true，对端点的连接就会持续等到远程服务的响应。
defaultSynchronousEventTimeout	属性	3000	等待一个同步响应的默认时间(ms)
defaultTransactionTimeout	属性	5000	事务默认的超时时间，没有指定时的默认值
Default-threading-profile	元素	无	默认的处理描述。在没有更详细的配置情况下，组件和端点用它来进行转发和接收。它可以被以下的三个覆盖。
Default-dispatcher-threading- Profile	元素	无	默认的发送处理描述。
Default-receiver-threading- Profile	元素	无	默认的接收处理描述。
Default-component-threading- Profile	元素	无	默认的组件处理描述。

 

Q&A

怎样配置sercerId?

在2.0中，一些系统属性在启动后是不可改变的，比如serverId。serverId不再被配置在xml配置文件中，你需要用启动参数-DMule.serverId=YOUR_MULE_SERVER_ID指定系统属性或者编程的方式下调用 org.mule.config.DefaultMuleConfiguratioin.setId()。

 

我如何为管理代理设置serverUrl?

在1.x中，在<mule-enviroment-properties>中指定一个serverUrl属性来启动管理代理。在2.x中，可以使用<remote-dispatcher-agent>来替代。详细参照org.mule.module.client.

Remoting.RemoteDispatcherAgent。

例如：

 

默认的队列描述，处理描述以及池化描述在哪里？

队列描述和处理描述配置在模型中，池化描述配置在池组件中。

配置端点

内容略

使用转换器

内容略

使用服务

介绍

一个服务组件是一个类、Web Service、或者其他的应用，它包含了你希望嵌入到Mule框架中的业务逻辑。例如，一个服务组件可以从用户数据库中添加信息到发货清单中，另一个服务组件可以是一个处理发货清单的订单执行应用程序。你可以使用现有的应用作为服务组件，也可以创建新的服务组件。

你的服务组件不需要包含Mule相关的代码。你需要配置服务，将服务用Mule相关的配置包装起来。服务配置指向服务组件，以及那些在服务组件间运送消息的路由器，过滤器以及转换器。它也可以指定服务用以接收消息的入站端点和为消息发往何处定位的出站端点。服务是完成集成解决方案的主要的Mule原件。

 

服务组件

一个服务组件可以是任意类型的对象，包括：

l Spring bean

l POJO

l Script

l Web Service or REST call

 

当创建一个服务组件时，你可以使用Mule IDE，这是一个Eclipse插件，它提供了开发Mule应用的集成开发环境

你还可以使用一些默认的组件，请参照使用默认的组件。

服务配置

绝大多数配置在服务级别上进行配置。服务可以使用全局定义的端点、转换器和过滤器或其他内部定义的组件来配置。

 

服务行为

当一个服务从入站端点接收到一个消息时，它处理入站消息和发送发站消息的行为由两方面决定：

l 服务模型（默认为SEDA）

 

l 消息模式

 

服务模型决定了处理和队列行为，而消息模型定义了入站和出站消息交换模式。

高级配置

你可以从以下方面进一步了解服务的配置：

l 事务

l 错误处理

l 安全(由端点配置)

 

配置服务

配置服务使用<service>和<model>两个元素。每一个<service>元素描述和配置了一个Mule服务，它会提供一个单一的名称来标识这一服务，你可以根据需要可选地配置状态，用于确定这一服务以及它的端点是否随Mule服务器的启动而启动。(初始状态包括启动、停止以及暂停)。

 

每一个服务都可以使用下面的可选元素进行配置：

l <description>：对服务的描述；

l <inbound>：配置入站路由及其端点，入站转换器；

l <component>：配置服务组件；

l <outbound>：配置出站路由及其端点，出站转换器；

l <async-reply>：配置异步响应路由，用于请求／响应方式的异步消息；

l <exception-strategy>：为消息配置异常处理策略。

 

如果你配置了多个上述元素，注意你必须按上面书写的顺序进行一一配置。关于<service>元素及其属性详情参见Service Configuration Reference。

下面是一个简单的服务配置：

 

 

下面是对这些元素进行的更加详细的介绍。

 

入站

这一元素用于配置入站端点和入站路由。端点通常接收进入系统的消息，入站路由则确定这些消息怎样被路由。入站端点和路由在<inbound>标签内分别进行配置。

入站端点用于接收进入的消息。一个端点就是一组简单的指示，指明了从哪个传输组件和哪个路径或地址接收消息，当然也包括必要接收消息中要使用的转换器，过滤器或者安全服务。你可以配置多个入站端点，每一个会从不同的传输组件是接收消息。更多内容参见Configuring Endpoints和Available Transports。

入站路由控制和操作一个服务接收到的消息，它是在消息被传送到该服务的服务组件前进行处理的。通常情况下，入站路由用于在接收消息时对这些消息进行过滤，聚合或重排序。入站路由也可以用于为一个服务注册多个入站端点。你可以将入站路由链接在一起，在消息传送到组件前，它需要与每一个路由都匹配一次。你可以配置一个catch-all-strategy用于处理不能被其他路由策略接收的消息。

入站路由不同于出站路由的地方在于，其端点是已知的（因为消息已经收到了），所以入站路由的目的在于怎样将消息传递给组件。

如果没有配置入站路由，默认情况下会使用InboundPassThroughRouter，它会简单地将进入的消息传送给组件。

只匹配首个路由

默认情况下，一个消息在被传送给服务组件前，它必须要匹配服务中所有的入站路由器，并被它们进行处理。如果你想配置服务，使进入的消息只被第一个条件匹配的路由器处理，你可以把<inbound>元素里的mathcAll属性设置为false。

需要更多关于入站路由器的信息，可以查看Mule Inbound Routers。

入站配置实例

 

这个例子中使用了一个元素<selective-consumer-router>来接收符合’resultcode’属性为’success’的消息。如果消息符合这一过滤器的标准，消息就会被送到这一组件。如果消息不符合，<catch-all-strategy>就会被调用，它会通过它的端点发送该消息，这个例子中是一个叫做失败队列JMS队列。

 

组件

<component>元素配置的服务组件，将在入站消息被入站路由器处理以后被调用。如果没有配置组件，这一服务就仅作为一个桥（Bridge），简单的将消息传送到出站路由器上。

当前可用并部署到Mule中的组件如下所示：

l 一些标准组件；

l <component/>：用于Java组件；

l <pooled-component/>：用于使用池的Java组件

l <script:component/>：用于基于脚本的组件；

l <test:component>：用于测试你的服务的组件（参见[Writing Functional Tests]）。

 

更多关于这些组件类型和配置的信息，可以看［Components］。你可以在你的Mule模型中实现新的组件类型，并将它们用于你的配置。在Mule 2.0中，实现和使用新的非Java组件类型，并将他们配置到自定义的组件里变得更加容易了。

 

出站

<outbound>元素配置出站路由器和它们的端点。因为出站路由器用于在组件处理完消息后，确定使用哪些端点来发送消息，所以出站路由器上需要配置出站端点，但并不是直接配置在<outbound>元素里。出站路由器允许开发者为任意消息定义多个出站约束。你可以为没有路由器接收的消息指定catch-all-strategy。更多信息参见Configuring Endpoints和Available Transports。

匹配所有路由器

默认情况下，消息只会被符合条件的第一个出站路由器处理。如果你想让消息被所有的路由器都处理，你要把matchAll属性设置为true。例如，假定你总是需要为原始的储户发送一个存款确认，并且如果存款额大于$100,000，你需要给‘高净值客户管理器’发送一个通知方便其可能的随访。在这个场景下，你可能会在<outbound>定义中设置matchAll属性：

 

在这个例子中，消息总会匹配第一个路由器，因为这个路由器没有过滤器。另外，如果存款额大于$100,000，消息还会和第二个路由器匹配，这时，两个路由器都会被调用。

更多关于出站路由器的信息，可以参考Mule Outbound Routers。

出站配置实例

 内容略

 

异步回复

这一元素用于配置那些需要在异步的请求／回复场景中接收回复的端点和路由器。这种情况下，你通常需要在当前服务响应经过它的入站端点前需要合并来自一个远程端点的多个响应消息。这里有一个经典的例子，当发送出一个请求，这个请求需要多个任务并行地执行。在响应被发回请求者之前，每一个任务都必须完成执行和结果处理。需要更多的关于可以使用的异步回复路由器的信息，请看Asynchronous Reply Routers。需要配置端点的资料，请看Configuring Endpoints。

异步回复路由器可以在请求／回复调用中联结叉状的任务。实际上，你可以使用在使用了异步调用的服务中使用异步回复路由器（因为当异步转发消息时是没有回复的）。Mule提供了聚合路由器，它可以用于联结消息分裂组件或者接收列表路由器，在返回回复前进行消息聚合。从Using Message Routers可以找到更多关于这些路由器的信息。

 

端点指定了响应应该被转发、进行处理的地址。路由器负责为用户将银行的开价聚合成一个开价。下面看一下LoanBroker配置中的入站和异步响应路由器配置：

 

这个配置指明了贷款中介将从vm:Loan.Requests中接收请求，并将多个请求通过出站路由转发到不同的银行。银行端点用被称为‘接收列表‘的列表进行定义，并作为出站消息的一个属性。出站路由中一个重要的配置是<reply-to>端点，它会告诉Mule，将所有的回复路由到jms:Loan.Quotes端点，这个端点就是异步响应路由器监听的端点。当所有的响应都后，BankQuotesResponseAggregator选择最廉价的开价，并返回它。然后Mule将其返回给请求者。<reply-to>端点然后被应用到下一个调用的服务上。例如，如果服务1将消息发送给服务2处理，并且服务1有一个包含reply-to端点的出站路由，那么，服务2将把它处理的结果发送到reply-to端点上。

响应转换器

如果你不对响应做其他处理，仅仅需要转换一下其消息格式，你可以在响应路由器(response-router)上配置一个转换器属性，而不做其他任何的路由配置。

 

回复

所有出站路由器可以有一个回复端点(reply-to endpoint)，它定义了消息处理者处理完成消息后，消息的路由。<reply-to>端点应用于下一个被调用的组件。例如，如果组件1将消息转发给组件2处理，组件1有一个含有<reply-to>的出站路由器，组件2会把它处理完的结果发送到<reply-to>端点上。<reply-to>端点可以是任意合法的端点URI，如果传输组件<reply-to>消息，它就会沿着消息方向将消息发送给下一个组件。关于传输器支持<reply-to>的信息，可以参见Available Transports。

 

超时

异步回复路由器超时设置决定了Mule会在返回结果前等待回复多久。其默认值由Mule实例中已配置的默认同步事件超时值决定。你也可以为使用可选的异步回复元素中的超时属性为一个服务的异步回复指定单独的超时值。

当在所有等待的消息被收到前，路由器出现超时异常的情况下，使用可选的failOnTimeout属性选择要不要抛出异常。如果设置为flase(默认值)，当前消息会被返回继续处理。

 

异常处理策略

异常策略用于在处理消息的过程中出现错误时处理异常。你可以为服务配置异常策略。如果没有配置异常策略，DefaultServiceExceptionStrategy将会被调用。

更多关于异常策略的信息，参见Error Handling。

 

服务桥

服务组件配置在Mule 2.0中是可选的。默认使用的组件是PassThroughComponent。这个组件自动地将入站消息连接到出站阶段，并简单地将消息传送到出站路由器上。如果你想将消息从一个传输器发送到另一个传输器，这种方式可以作为桥端点。

示例：读取文件并将它的内容发送到Jms Topic。

 

 

服务模型

Mule默认使用分阶段的事件驱动架构模型（SEDA）。SEDA中，应用程序包括一个连接着明确的队列上的事件驱动阶段的网络，这样的架构保证服务可以被很好的加载，防止在需要过度的服务能力时资源会被过量使用。因此，SEDA提供了一个效率很高的队列模型，来最大限度地提高性能和吞吐量。

参照Models，可以得到更多可选择的模型以及怎样实现满足自己需要的模型。

 

服务消息模式

消息模式决定了消息交换模式，它用在入站和出站端点上，来保证这些端点可以配置成异步请求/响应，异步参与或者其他模式。

消息模式配置在端点上，保证多种模式都可以用在同一个服务上。更多信息参见[Messaging Patterns]。

 

配置组件

内容略

使用消息路由器

消息路由器用于在系统中控制组件对事件的发送和接收。Mule定义入站路由器用于处理接收到的事件，定义了出站路由器，在事件被转发时调用。

Mule为你的组件提供了灵活的消息路由支持。路由的特点基于企业集成模式一书描述的企业路由要求。

 

入站路由

当一个消息通过端点被接收到后，入站路由控制消息怎样进入服务。下面是对入站路由的介绍和配置方法。

 

Pass-through Router

这个路由总是可以匹配的，它简单的将进入的消息报传送到服务组件。没有路由器配置的情况下，会默认使用这个路由器。

 

Selective Consumer

一个Selective Consumer入站路由器可以对进入的消息应用于一个或多个过滤器。如果过滤器匹配，消息就会被发送到相应的组件。否则，消息会被转发到路由器的catch-all-strategy。如果没有配置catch-all，消息就会被忽略掉，并且系统会记录一个警告。这个路由器的配置如下：

 

注意默认情况下，过滤器会在入站转换器处理完消息后，才被调用。如果你需要在转换器调用之前对消息执行过滤功能，你可以设置路由器的transformFirst属性。

 

 

Idempotent Receiver

 

使用过滤器

过滤器指定了被路由到特定服务组件的消息必须满足的条件。在Mule中，你可以使用多种标准的过滤器，也可以自己创建过滤器。

你可以创建全局的过滤器，然后在你的服务中引用它。全局过滤器需要一个"name"属性，过滤器是配置在端点上的，而路由器则不是。

 

标准的过滤器

Mule中，你可以将以下标准过滤器使用到你的路由器中。

Payload Type Filter

Expression Filter

RegEx Filter

Wildcard Filter

Exception Type Filter

Message Property Filter

Logic Filter

后面的文章中将对此进行一一介绍。