mule in action翻译10 : 2.2 和消息交互
2.2 和消息交互
mule支持几种交互方式,交互的结果是创建新的消息或者是处理一个已经存在的消息。
先学习消息交互中非常重要的术语:
Receiving-- 接收 : 发生在消息源处,当一个外部的事件发生时
(比如一个HTTP请求 或来自JMS的消息),将产生一个新的mule消息。
Polling-- 轮询: 也发生消息源处,mule主动发起的,以一个特定的频率发生,也会生成新的mule消息。
Dispatching--分发:发生在消息处理器处,mule向外发出消息后不会等待响应。
Sending--发送: 发生在消息处理器处,mule发出消息后会等待同步响应。
这个响应会产生一个新的mule消息。
Requesting--请求:以编程的方式发生,从某个源取回数据后会生成新的mule消息
(例如从读入某个文件的内容或消费JMS队列的消息)
对这些交互方式的支持 依赖于mule的一些核心概念,这实际是其它消息处理的基础。
本部分学习下列概念:
消息源
消息处理器
消息交换方式
Endpoint URIs
2.2.1 消息源
在mule配置中消息源一般也作为接入端口( inbound endpoints)。轮询器一般也会使用消息源。
云连接器也会提供消息源,并可用在配置文件中。
一个流中只能有一个消息源。为了从多个接入端口生成消息,必须使用复合消息源。
复合消息源当然也是一个消息源。下面列表展示了一些有效的消息源,其中就有复合消息源
Listing 2.7 Simple and composite message sources
<vm:inbound-endpoint path="payment-processor" /> <composite-source> <jms:inbound-endpoint queue="payment-processor" /> <http:inbound-endpoint host="localhost" port="8080" path="payment-processor" /> </composite-source>
复合消息源: 复合消息源的每个端口(endpoint)当收到消息后将会启动一个新的执行流。
复合消息源不限制传输协议,不限制交互方式。
2.2.2 消息处理器
消息处理器是mule配置的基本构成模块。除了消息源,流基本上都是有消息处理器组成。
消息处理器执行mule中所有的消息处理操作,在而配置文件中消息处理器有多种元素。
消息处理器的主要功能:
1、 作为 接出端口(outbound endpoints ),分发消息到目的地。
2、 作为 转换器(transformers) ,能够修改消息。
3、 作为 路由器(routers),保证把消息发送到正确目的地。
4、 作为 组件(components),执行对消息的业务操作。
多数时候,你只需要配置信息处理器。你配置文件中看到的转换器、组件、端口都是消息处理器。
实际上多样的消息处理器是mule实现功能多样性的关键。你可以在配置文件中自由的组合他们。
各种消息处理器实质上是相同的,他们是可以互换的。
把消息处理器硬塞进一个链 当本地配置文件只允许一个消息处理器时,
可以使用 processor-chain 元素,这个处理器封装了多个按顺序被调用的消息处理器(就像一个链一样)
实现org.mule.api.processor.MessageProcessor,可以创建客户化的消息处理器,并可配置在配置文件中。
这非常有用,代价是要直接暴露给mule内部构件。
2.2.3 消息交换方式
消息交换方式(Message exchange patterns--MEP),描述接入端口和接出端口的连接方式。
通过定义端口交互是同步的还是异步的,MEP会影响端口的两边
(发送者和接收者,或者说是客户端和服务端)
当前mule只支持两种 MEP:
1、One-way 单向式, 此交互不需要返回同步的响应。
2、Request-response 请求-响应式,需要返回同步的响应。
两种MEP都可以用在接入端口和接出端口,但一些传输协议可能会限制交换方式(比如POP3是单向的)。
在接入端口,单向式意味着mule不必给调用者返回响应,而请求-响应式则需返回。
在接出端口,单向式意味着mule不必等待被调用者返回响应,即使返回响应也会被忽略掉,
而请求-响应式则需等待响应。
说些别的 当客户端调用了一个单向式服务后,将会阻塞住并等待响应,它将收到一个空的响应。
例如向一个in-only HTTP 接入端口发送GET请求,将收到空的响应(内容长度是0)
和一个200 ok 的状态码。
需要注意的例外是 VM的transport;客户端和服务端都必须同意其交换方式否则消息交换会失败。
不要把单向式和 fire-and-forget混为一谈。mule保证消息得到正确传递。
例如,当向单向式JMS端口( JMS endpoint)
分发消息时,mule会保证消息得到可靠的传送,否则会抛出异常。这同样适用于单向式的HTTP端口,
其与request-response的最大的不同是 当mule只收到响应的状态码就行了不管其他的了。
--收到响应码表示对方成功接收。
举例说明,看列表2.8中的两个不同的HTTP endpoints ,
各自的MEP不同(通过 exchange-pattern属性配置)。
接入端口使用request-response MEP,它将提供同步的响应给发送HTTP请求的客户端。
接出端口是one-way,意味着mule(作为客户端)将不会等待远程服务器的响应,
不管服务端是否返回了响应。
Listing 2.8 HTTP endpoints with different exchange patterns
<http:inbound-endpoint host="localhost" port="8080" path="payment-processor" exchange-pattern="request-response" /> <http:outbound-endpoint host="localhost" port="8081" path="notifier" exchange-pattern="one-way" />
MEP 影响了消息交互的时间轴;equest-response是时间上紧密连接的,而one-way避免了这种情况。
MEP 会直接严重影响mule的并发处理,当高并发时,流的执行会出现难以预料的情况。
看下面配置:
Listing 2.9 A simple flow in which execution doesn’t happen as expected
<flow name="acmeApiBridge"> <vm:inbound-endpoint path="invokeAcmeAmi" /> <jdbc:outbound-endpoint queryKey="storeData" /> <http:outbound-endpoint address="http://acme.com/api" /> </flow>
Prancing Donkey 公司使用这个配置把HTTP会话状态保存到数据库。
当建立一个连接 Acme Corp API 的新会话时会使用到这个流。
在另一个流中,HTTP的响应会进一步修改会话的状态。
这个流中不时的出现HTTP请求在 JDBC 完成insert前被分发出去的现象,
可是在配置文件中jdbc 明明是在http之前啊,这真是让人困惑。
这怎么可能?
看一下日志记录:
DEBUG acmeApiBridge.stage1.02 [HttpConnector]
Borrowing a dispatcher for endpoint: http://acme.com/api
INFO jdbcConnector.dispatcher.01 [SimpleUpdateSqlStatementStrategy]
Executing SQL statement: 1 row(s) updated
DEBUG acmeApiBridge.stage1.02 [HttpClientMessageDispatcher]
Connecting: HttpClientMessageDispatcher{this=1e492d8,
endpoint=http://acme.com/api, disposed=false}
注意线程的名字(在日志级别和类名之间的方括号内)。
你看到什么? 你发现JDBC insert是被一个主线程之外的独立线程执行的。
为什么mule使用一个单独的线程执行jdbc操作?
答案关键在于每个 endpoint使用的消息交换方式。
注意上面的这个流没有指定消息交换方式,这会使用默认的交换方式:
jdbc是one-way的,HTTP是request-response的。
因为是one-way的,mule知道不用期待返回响应,所以才使用一个单独的线程处理。
图2.6 说明了one-way 的MEP如何进行并行处理。
在5.3.3节,我们再看其它的进行消息并行处理的方式。
不要玩猜字游戏 要是你的流清晰明了,不要依赖于默认设置,要在你的endpoints中使用显示的 MEP配置。
2.2.4 Endpoint URIs
mule使用统一资源标示符(URI) 作为他对外暴露的或是通过endpoints访问的资源的统一的表示。
换句话说,inbound和outbound在内部使用URI进行配置。
在xml配置文件中他们由不同的元素、不同的属性进行配置。
实际上,这些不同元素不同属性的配置最后都将组合成一个endpoint URI。
看下例。 URI用来表示HTTP资源大家很熟悉了,请注意JMS和TCP怎配置的。
http://localhost:8080/products
jms:topic://news
tcp://localhost:51000?connector=pollingTcpConnector
完整的如列表2.10 ,展示了mule使用URI暴露资源的配置。
Listing 2.10 Mule endpoints exposing different types of resources
<http:inbound-endpoint host="localhost" port="8080" path="products" /> <jms:inbound-endpoint topic="news" /> <tcp:inbound-endpoint host="localhost" port="51000" connector-ref="pollingTcpConnector" />
相关推荐
Mule in Action, Second Edition is a totally-revised guide covering Mule 3 fundamentals and best practices. It starts with a quick ESB overview and then dives into rich examples covering core concepts ...
《Mule in Action》一书深入探讨了Mule——一个轻量级消息框架与高度分布式的对象代理系统,为读者提供了全面的理论与实践指导。本书由David Dossot和John D'Emic共同撰写,旨在帮助开发者掌握Mule的核心功能与配置...
### Mule in Action 第二版 英文正式版 关键知识点概述 #### 一、书籍简介与背景 《Mule in Action》第二版是一本详细介绍Mule ESB(Enterprise Service Bus)这一著名开源框架的书籍。该书由David Dossot、John D...
《Mule in Action》是一本专注于Mule ESB(企业服务总线)的入门教程,旨在帮助读者系统地学习和理解这一强大的集成平台。Mule ESB是开源领域中的一个重量级选手,常用于构建灵活、可扩展的企业级集成解决方案。这...
mule in action 和doc文档详细介绍 Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑。UMO可以是POJO,JavaBean等等。它支持30多种传输协议...
Mule in Action is acomprehensive tutorial designed for working Java developers. This authoritativebook explores the architecture and the main features of version Mule 2 throughnumerous running ...
《Mule in Action》这本书是关于Mule ESB(企业服务总线)的权威指南,由David Chappell和James Strachan等作者撰写。Mule ESB是一种开源的集成平台,它允许开发者轻松地连接各种系统、服务和应用程序,实现数据的...
总体而言,Mule in Action, Second Edition这本书是关于Mule ESB使用和集成实践的权威指南,涵盖了从基础概念到高级特性的广泛主题。本书适合于那些希望深入学习和利用Mule ESB进行企业级应用集成的开发人员和架构师...
《Mule in Action》是关于Mule ESB的实战指南,该书深入浅出地介绍了如何使用Mule这一强大的企业服务总线(ESB)进行应用程序集成。Mule ESB以其用户基数庞大、文档详尽以及社区活跃而备受赞誉,是企业级集成解决...
Mule in Action是一本关于Mule ESB(企业服务总线)的实战指南,旨在为读者提供深入的实践知识和案例分析。ESB作为一种流行的中间件技术,用于实现不同系统之间的服务集成。Mule作为一个开源的ESB解决方案,通过其...
《Mule in Action》第二版是一本全面介绍如何使用Mule ESB进行高效集成开发的书籍,由David Dossot、John D’Emic和Victor Romero共同编写。 #### 二、Mule ESB的关键特性 **1. 消息处理:** Mule ESB支持多种消息...
1. **Mule核心组件**:理解Mule的消息传递机制,如Inbound Endpoints(输入端点)、Outbound Endpoints(输出端点)、Transformers(转换器)和Filters(过滤器),这些都是构建Mule流程的基础。 2. **ESB概念**:...
MULE IN ACTION Mule是一个企业服务总线(ESB)消息框架,它为集成不同系统和应用程序提供了一种轻量级的、易于使用的方法。Mule的设计哲学围绕着灵活性和可扩展性,通过其高度可插拔的架构,支持多种传输协议和...