使用服务
介绍
一个服务组件是一个类、Web Service、或者其他的应用，它包含了你希望嵌入到Mule框架中的业务逻辑。例如，一个服务组件可以从用户数据库中添加信息到发货清单中，另一个服务组件可以是一个处理发货清单的订单执行应用程序。你可以使用现有的应用作为服务组件，也可以创建新的服务组件。
你的服务组件不需要包含Mule相关的代码。你需要配置服务，将服务用Mule相关的配置包装起来。服务配置指向服务组件，以及那些在服务组件间运送消息的路由器，过滤器以及转换器。它也可以指定服务用以接收消息的入站端点和为消息发往何处定位的出站端点。服务是完成集成解决方案的主要的Mule原件。
服务组件
一个服务组件可以是任意类型的对象，包括：
l Spring bean
l POJO
l Script
l Web Service or REST call
当创建一个服务组件时，你可以使用Mule IDE，这是一个Eclipse插件，它提供了开发Mule应用的集成开发环境
你还可以使用一些默认的组件，请参照使用默认的组件。
服务配置
绝大多数配置在服务级别上进行配置。服务可以使用全局定义的端点、转换器和过滤器或其他内部定义的组件来配置。
服务行为
当一个服务从入站端点接收到一个消息时，它处理入站消息和发送发站消息的行为由两方面决定：
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
后面的文章中将对此进行一一介绍。
扫一扫
9305
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
