想问下， mule 有没有类似xwork 拦截器的机制吗， 麻烦有知道的能说下， 现在需要把通过mule总线的服务请求记录下来；；；；
配置过滤器就行
[code="java"]
ESB集成框架Mule简要介绍
mule
10-9-9 下午12:26 .
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定义了两个或者多个组建应用或者存储库之间的通信渠道。并且提供了一个强大的机制来允许你的对象在一个统一的方式上再多种协议之上进行交谈。端点可以通过消息过滤器、安全拦截器和事务信息进行配置来控制什么消息，在何时，以及怎样通过端点进行发送和接收。[/code]
[code="java"]配置概述
１． 配置文件
默认的，并且最常的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风格的属性占位符，例如：
正如这一节中描述的，这些占位符的值可以有很多种方法赋予
全局变量
你可以使用元素来从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配置变量可以用标签进行配置。例如：
所有可用的变量如下表所示：
变量
类型
默认值
描述
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中，在中指定一个serverUrl属性来启动管理代理。在2.x中，可以使用来替代。详细参照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 安全(由端点配置)
配置服务
配置服务使用和两个元素。每一个元素描述和配置了一个Mule服务，它会提供一个单一的名称来标识这一服务，你可以根据需要可选地配置状态，用于确定这一服务以及它的端点是否随Mule服务器的启动而启动。(初始状态包括启动、停止以及暂停)。
每一个服务都可以使用下面的可选元素进行配置：
l ：对服务的描述；
l ：配置入站路由及其端点，入站转换器；
l ：配置服务组件；
l ：配置出站路由及其端点，出站转换器；
l ：配置异步响应路由，用于请求／响应方式的异步消息；
l ：为消息配置异常处理策略。
如果你配置了多个上述元素，注意你必须按上面书写的顺序进行一一配置。关于元素及其属性详情参见Service Configuration Reference。
下面是一个简单的服务配置：
下面是对这些元素进行的更加详细的介绍。
入站
这一元素用于配置入站端点和入站路由。端点通常接收进入系统的消息，入站路由则确定这些消息怎样被路由。入站端点和路由在标签内分别进行配置。
入站端点用于接收进入的消息。一个端点就是一组简单的指示，指明了从哪个传输组件和哪个路径或地址接收消息，当然也包括必要接收消息中要使用的转换器，过滤器或者安全服务。你可以配置多个入站端点，每一个会从不同的传输组件是接收消息。更多内容参见Configuring Endpoints和Available Transports。
入站路由控制和操作一个服务接收到的消息，它是在消息被传送到该服务的服务组件前进行处理的。通常情况下，入站路由用于在接收消息时对这些消息进行过滤，聚合或重排序。入站路由也可以用于为一个服务注册多个入站端点。你可以将入站路由链接在一起，在消息传送到组件前，它需要与每一个路由都匹配一次。你可以配置一个catch-all-strategy用于处理不能被其他路由策略接收的消息。
入站路由不同于出站路由的地方在于，其端点是已知的（因为消息已经收到了），所以入站路由的目的在于怎样将消息传递给组件。
如果没有配置入站路由，默认情况下会使用InboundPassThroughRouter，它会简单地将进入的消息传送给组件。
只匹配首个路由
默认情况下，一个消息在被传送给服务组件前，它必须要匹配服务中所有的入站路由器，并被它们进行处理。如果你想配置服务，使进入的消息只被第一个条件匹配的路由器处理，你可以把元素里的mathcAll属性设置为false。
需要更多关于入站路由器的信息，可以查看Mule Inbound Routers。
入站配置实例
这个例子中使用了一个元素来接收符合’resultcode’属性为’success’的消息。如果消息符合这一过滤器的标准，消息就会被送到这一组件。如果消息不符合，就会被调用，它会通过它的端点发送该消息，这个例子中是一个叫做失败队列JMS队列。
组件
元素配置的服务组件，将在入站消息被入站路由器处理以后被调用。如果没有配置组件，这一服务就仅作为一个桥（Bridge），简单的将消息传送到出站路由器上。
当前可用并部署到Mule中的组件如下所示：
l 一些标准组件；
l ：用于Java组件；
l ：用于使用池的Java组件
l script:component/：用于基于脚本的组件；
l test:component：用于测试你的服务的组件（参见[Writing Functional Tests]）。
更多关于这些组件类型和配置的信息，可以看［Components］。你可以在你的Mule模型中实现新的组件类型，并将它们用于你的配置。在Mule 2.0中，实现和使用新的非Java组件类型，并将他们配置到自定义的组件里变得更加容易了。
出站
元素配置出站路由器和它们的端点。因为出站路由器用于在组件处理完消息后，确定使用哪些端点来发送消息，所以出站路由器上需要配置出站端点，但并不是直接配置在元素里。出站路由器允许开发者为任意消息定义多个出站约束。你可以为没有路由器接收的消息指定catch-all-strategy。更多信息参见Configuring Endpoints和Available Transports。
匹配所有路由器
默认情况下，消息只会被符合条件的第一个出站路由器处理。如果你想让消息被所有的路由器都处理，你要把matchAll属性设置为true。例如，假定你总是需要为原始的储户发送一个存款确认，并且如果存款额大于$100,000，你需要给‘高净值客户管理器’发送一个通知方便其可能的随访。在这个场景下，你可能会在定义中设置matchAll属性：
在这个例子中，消息总会匹配第一个路由器，因为这个路由器没有过滤器。另外，如果存款额大于$100,000，消息还会和第二个路由器匹配，这时，两个路由器都会被调用。
更多关于出站路由器的信息，可以参考Mule Outbound Routers。
出站配置实例
异步回复
这一元素用于配置那些需要在异步的请求／回复场景中接收回复的端点和路由器。这种情况下，你通常需要在当前服务响应经过它的入站端点前需要合并来自一个远程端点的多个响应消息。这里有一个经典的例子，当发送出一个请求，这个请求需要多个任务并行地执行。在响应被发回请求者之前，每一个任务都必须完成执行和结果处理。需要更多的关于可以使用的异步回复路由器的信息，请看Asynchronous Reply Routers。需要配置端点的资料，请看Configuring Endpoints。
异步回复路由器可以在请求／回复调用中联结叉状的任务。实际上，你可以使用在使用了异步调用的服务中使用异步回复路由器（因为当异步转发消息时是没有回复的）。Mule提供了聚合路由器，它可以用于联结消息分裂组件或者接收列表路由器，在返回回复前进行消息聚合。从Using Message Routers可以找到更多关于这些路由器的信息。
端点指定了响应应该被转发、进行处理的地址。路由器负责为用户将银行的开价聚合成一个开价。下面看一下LoanBroker配置中的入站和异步响应路由器配置：
这个配置指明了贷款中介将从vm:Loan.Requests中接收请求，并将多个请求通过出站路由转发到不同的银行。银行端点用被称为‘接收列表‘的列表进行定义，并作为出站消息的一个属性。出站路由中一个重要的配置是端点，它会告诉Mule，将所有的回复路由到jms:Loan.Quotes端点，这个端点就是异步响应路由器监听的端点。当所有的响应都后，BankQuotesResponseAggregator选择最廉价的开价，并返回它。然后Mule将其返回给请求者。端点然后被应用到下一个调用的服务上。例如，如果服务1将消息发送给服务2处理，并且服务1有一个包含reply-to端点的出站路由，那么，服务2将把它处理的结果发送到reply-to端点上。
响应转换器
如果你不对响应做其他处理，仅仅需要转换一下其消息格式，你可以在响应路由器(response-router)上配置一个转换器属性，而不做其他任何的路由配置。
回复
所有出站路由器可以有一个回复端点(reply-to endpoint)，它定义了消息处理者处理完成消息后，消息的路由。端点应用于下一个被调用的组件。例如，如果组件1将消息转发给组件2处理，组件1有一个含有的出站路由器，组件2会把它处理完的结果发送到端点上。端点可以是任意合法的端点URI，如果传输组件消息，它就会沿着消息方向将消息发送给下一个组件。关于传输器支持的信息，可以参见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
下面将一一介绍。
Mule消息样式
使用Web Service
配置Mule和Apache Axis。
l Getting started - 介绍通过Axis暴露Mule Service和调用Soap Service。
l Axis Transport - Axis连接器的基本配置。
l Configuring Axis - 控制WSDL generation, 指定参数,高级服务配置 等等。
l Axis SOAP Transports - 通过JMS,Vm,Smtp和其他Mule传输器来使用Axis。
l Axis SOAP Styles - 为Doc/Lit, Message or RPC形式的调用配置服务。
使用Spring服务组件
你可以从Spring bean中构建服务组件，这些bean可以是在独立的Spring配置文件中定义的，也可以是在Mule配置文件中定义的。这一节里提供了使用两个bean的例子：RestaurantWaiter接收和记录主要问题，然后把订单传送给接收订单的KitchenService。
定义Beans
Bean的Java代码如下：
配置Beans
首先，在Spring应用环境中配置beans：
现在，我们就有了Spring创建的叫做restaurantWaiter和kitchenService的bean。注意resturantWaiter没有被声明为单例模式（默认情况下，如果特别指定，Spring中的bean都是单例模式的）。这非常重要，因为Mule会集中你的组件，并告诉Spring不要创建单例的bean，确保每个组件实例都是唯一的实例。
如果你想在你的Mule配置文件中配置bean，而不是在单独的Spring配置文件夹中，你需要这样定义它们：
配置组件
在配置完成bean后，你就可以在组件中创建你的restaurantWaiter的引用。比如，下面的配置创建了一个让restaurantWaiter接收来自VM的事件的组件，这个例子假设bean是配置在单独的文件中的，所以如果你在Mule配置文件中配置它们时，需要使用spring:import标签。
当Mule服务器启动时，每一个元素都会被加载，并且标签中的bean会创建好。当一个事件被vm://order.queue接收到，一个订单对象就被传送到RestaurantWaiter上的takeOrder()方法，然后该方法会记录订单并把它传送给KitchenService。
使用JNDI和EJB会话Beans
如果你在Spring中使用定义了JNDI和EJB bean，你需要在Mule中像配置其他Spring bean一样正确地配置它们。然而，如果你使用定义它们(jee:jndi-lookup,jee:local-slsb,jee:remote-slsb)，你必须在Mule配置文件中包括进Jee名字空间和结构定义的地址，如下所示：
定制行为
开发服务组件
在开发服务组件时，你关注的是开发处理业务逻辑的代码，而不是用Mule去集成服务组件。比如，如果你要开发一个向销货清单中添加顾客数据的服务组件，你关注于写代码查询顾客数据库和根据需要更新销货清单。你不需要写任何特别的代码来处理那些需要传送到服务组件或者与Mule进行集成的消息，因为所有的集成服务都通过配置来完成。你可以把服务组件开发成Pojo，或者Web service，这些Web Service可以是使用各种流行的窗口，比如Spring，EJB或者Plexus。
Mule的确可以让你使用服务组件得到当前消息的信息，甚至控制这些消息，而不是仅仅使用消息的负载来进行工作。为了保证服务组件可以直接同消息进行协作，你必须实现服务组件的Callable()接口。（见下面的Entry Points入口点）
你可以使用Mule IDE来开始开发Mule服务组件。Mule IDE是一个Eclipse插件，它提供了开发Mule应用的集成开发环境。你可以使用Mule提供的标准组件，或者以它们为出发点构建自己的组件。
Entry Point入口点
Entry point是你的组件中的一个方法，它会在一条消息到达Mule时，被调用。Mule使用入口点解决方案来基于消息的负载类型动态地选择调用方法。如果组件中有多个方法匹配负荷类型，或没有方法匹配时，会抛出一个错误异常。
另一种可选择的方法是，你的组件可以实现org.mule.api.lifecycle.Callable接口。如果你的组件实现了这个接口，它将会覆盖掉所有的动态解决方案，转而调用这个接口的实现方法。
你也可以调用组件中没有任何参数的方法，更多信息参见下面的Calling No-args Methods。
如果你想创建自己的入口点解决方案，你需要创建一个实现了EntryPointResolver接口的类，并在Mule配置文件中使用指定它。
关于配置入口点解决方案的详细信息，参见Entry Point Resolver Configuration Reference。
默认消息流行为
Mule有一些默认的出入组件的消息流的行为规则。
1.当消息接收时，入口点方法被调用。
2.回复或者出站消息以如下方式得到：
如果调用的方法不是void的，也就是Callable.onEvent()返回一个Object，方法的返回值就会被使用。如果返回为空值，当前的请求就不再会有进一步的处理。
如果调用的方法是void的，用于调用该方法的参数会被使用。这是假定参数本身改变了或者消息是没有改变的。
3.如果入站端点以同步方式使用，组件调用的结果会被返回给请求者。
4.出站消息通过服务的配置进行路由。
关于更多关于不同的配置选项影响消息流的细节，参照Mule Messaging Styles。
定制消息流行为
为了定制消息流行为，你必须得到一个org.mule.api.MuleEventContext的引用。你可以实现Callable接口来得到这个引用，它将把事件的上下文作为这个接口的参数：
从MuleEventContext中，你可以发送和接收同步和异步的事件，管理事务，覆盖默认的事件流行为，比如：
即使当你使用事件上下文来人工控制事件流时，在方法返回时，Mule会正常地路由出站消息。你可以这样来让Mule停止继续处理事件：
如果你的服务方法不是void的，你可以返回空。这种方式将告诉Mule，没有进一步的事件消息要处理了。
如果你的服务方法是void的，Mule将会使用入站消息负载作为出站消息负载。你可以使用下面的调用重写这个行为：
注意：在控制消息流的组件实现上，使用附加的服务或者使用组件绑定比以上方法更值得提倡。因为它提供了更多的解耦的实现，这样就可以通过配置文件来进行修改，避免了使用Mule API来实现。为了在两者间作出选择：
1.保证你的服务组件以这样的方式来实现，它们不需要做任何的消息发送／接收就能完成一个单元的工作。这些附加的发送／接收／路由工作都使用mule服务来完成。
2.这样来设计你的组件，接口的方法可以映射到出站端点，并且使用绑定将它们映射到配置文件中。配置绑定的更多信息参见Configuring Java Components。
组件生命周期
可选地，你的组件可以实现多个生命周期接口。下面是一些非常通用的接口：
l org.mule.api.lifecycle.Initialisable，它在组件的生命周期中只被调用一次。它在组件池初始化时，创建组件时被调用。
l org.mule.api.lifecycle.Startable，它在组件启动是被调用。
l org.mule.api.lifecycle.Stopable，它在组件停止时被调用。
l org.mule.api.lifecycle.Disposable，它在组件需要时调用。
......
调用无参数的方法
......
创建自定义的转换器
转换器按照服务组件的需要把入站数据转换为一种类型。它们当然也可以把出站数据按照传输器的需要转换为一种类型，比如JMS消息。你可以在入站端点上配置转换器，保证服务组件可以接收到想要的类型的数据。也可以配置到出站端点上，保证端点在发送消息前接收到正确对象类型。你也可以把多个转换器链接起来，这就使合适粒度的转换器可以容易地重用。
Mule提供了多种转换器，包括XML转换器，(比如XML到Object、XSLT，DOM到XML)，加密和解密数据的加密转换器，压缩和解压缩数据的压缩转换器，编码转换器(比如Base 64和SGML实体编码和解码)，和序列化和反序列化对象并且在字符串和字节数组间转换的对象转换器。可以从Using Transformers中得到一个Mule中默认转换器的列表。
创建你自己的转换器，你需要实现抽象类org.mule.transformers.AbstractTransformer。这个类是一个抽象的转换器实现，它定义了对转换器所支持的对象类型的控制，验证期待的返回类型的方法，开发者仅需要实现一个transform()方法。如果转换器需要访问进入的事件，你可以实现AbstractEventAwareTransformer，它是AbstractTransformer的子类，提供了对事件上下文的访问。
创建自定义的路由器
尚无内容(20080825)
创建自定义的过滤器
见使用过滤器最后一节
使用拦截器
尚无内容(20080825)
创建自定义的入口解决方案(entry point resolver)
你可以使用默认的或自己创建的入口点解决方案的一个。关于配置入口点解决方案的的更详细信息，参见Entry Point Resolver Configuratioin Reference。
[/code]