[SOA] Mule ESB 3.x 入门(一)—— 消息流

标签: soa mule esb | 发表时间:2013-08-11 23:26 | 作者:fangxinggood
出处:http://blog.csdn.net

关于Mule ESB,简单来说Mule接受一个消息,按照某种顺序处理这个消息,这样的处理可导致多种结果。有时,Mule改变或变换消息返回到原来的消息来源(request-response)。或者,在其原有的基础上改变形式发送到一个或多个第三方(router, transfer)。而在其他一些情况下,如果消息没有达到的具体要求,Mule可以拒绝处理的消息validation, throttling)。

Mule 从3.0开始采用 flow 为单元的配置方式控制消息流(Mule 2.x 中使用 <service>),利用 Mule IDE 通过可视化的 flow blocks 来组装 flow。就像一个管道,消息从一端流向另一端。流动的消息,在 Mule 里被定义为 MuleMessage,它的结构就像下面这个样子:




它由三大部分组成:1. header(消息头):按照范围划分的属性;2. payload(消息体);3. attachments(附件)。我们可以在 flow blocks 中,通过编程方式读取或者设置这些内容。在 Mule 开发中,会遇到一个概念:"transport barrier" (传输障碍)。比如:调用子流程没有“transport barrier",而跨端点则需要跨越"transport barrier"。其中,消息头的按照范围划分属性具有以下的特性:

Mule Inbound Properties
  • Inbound Properties 是不能被修改的
  • Inbound Properties 由消息来源(如入站端点)设置
  • Inbound Properties 在跨越“transport barrier" 时丢失
Mule Outbound Properties
  • Outbound Properties 可以被设置
  • 在跨越“交通障碍”,Outbound Properties自动变成Inbound Properties
Mule Invocation Properties
  • Invocation Properties 可以被设置
  • Invocation Properties 在跨越“transport barrier" 时丢失
Mule Session Properties
  • Session Properties 可以被设置
  • Session Properties 在跨越“transport barrier" 时仍然会保持
Mule Flow Variable
  • 它们就像实例属性

Mule Session Variable
  • 它们就像Session Properties
根据上面的属性就可以知道 request 来的属性都存放在哪,response的属性应该如何控制。
下面就是 Mule 开发中比较常见的一种 flow —— request-response


一个简单的例子:通过 Http Endpoint 暴露出访问地址,客户端提交的请求经过 testFlow1 处理返回 response。中间记录一些log。

    <flow name="mule-maven-testFlow1" doc:name="mule-maven-testFlow1">
        <http:inbound-endpoint exchange-pattern="request-response" address="http://localhost:8089/test" doc:name="HTTP"/>
        <logger message="#[headers:INBOUND:*]" level="INFO" doc:name="Logger Headers"/>
        <scripting:component doc:name="Groovy">
            <scripting:script engine="Groovy" file="scripts/build-response.groovy"/>
        </scripting:component>
        <logger message="#[groovy:message.toString()]" level="INFO" doc:name="Logger Message"/>
    </flow>
首先用 logger component 记录一下请求的 header 信息,然后交给 groovy 构造 response 返回。
def contentType = message.getInboundProperty("Content-Type");
def response = "";
if (contentType == "application/xml") {
	response = "<string>hello world</string>"
} else {
	response = '{"string":"hello world"}'
}

response
groovy脚本判断 request 的 content-type 如果是 application/xml 那么返回 xml 内容,如果是 application/json 那么返回 json 内容。

通过 fiddler 模拟客户端对 http://localhost:8089/test  发送一个GET请求:
通过 Mule IDE 控制台可以看到接收到的消息头内容:

INFO  2013-08-11 23:08:50,473 [[mule-maven-test].connector.http.mule.default.receiver.03] org.mule.api.processor.LoggerMessageProcessor: {http.request=/test, Host=localhost:8089, http.method=GET, http.headers={Host=localhost:8089, User-Agent=Fiddler, Keep-Alive=false, Connection=false, Content-Type=application/xml}, http.relative.path=, User-Agent=Fiddler, http.request.path=/test, MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.8089.test, Connection=false, http.query.string=, http.context.path=/test, http.context.uri=http://localhost:8089/test, http.version=HTTP/1.1, http.query.params={}, MULE_REMOTE_CLIENT_ADDRESS=/0:0:0:0:0:0:0:1:24210, Keep-Alive=false, Content-Type=application/xml}

随便说一下关于logger的写法:

<logger message="#[headers:INBOUND:*]" level="INFO" doc:name="Logger Headers"/>  输出所有的 inbound headers 属性(Map)
<logger message="#[headers:INBOUND:Host]" level="INFO" doc:name="Logger Header Property"/>  输出 inbound header 里的某一个属性
<logger message="#[groovy:message.getInboundProperty('Host')]" level="INFO" doc:name="Logger Host Value"/> 直接输出inbound property 里的某一属性的值
<logger message="#[groovy:message.toString()]" level="INFO" doc:name="Logger Message"/> 输出 Mule Message
(注意:直接 #[groovy:message] 或者 #[message.toString()] 都不好使,那只会输出对象的引用地址)

在多数场景下,直接输出 Mule Message 会更有跟踪价值,打印出来的 Mule Message 结构如下,你可以很清楚的观察到 Message 在 flow 里的变化。
org.mule.DefaultMuleMessage
{
  id=edced872-0297-11e3-ada6-610a86bd1f23
  payload=java.lang.String
  correlationId=<not set>
  correlationGroup=-1
  correlationSeq=-1
  encoding=UTF-8
  exceptionPayload=<not set>

Message properties:
  INVOCATION scoped properties:
  INBOUND scoped properties:
    Connection=false
    Content-Type=application/xml
    Host=localhost:8089
    Keep-Alive=false
    MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.8089.test
    MULE_REMOTE_CLIENT_ADDRESS=/0:0:0:0:0:0:0:1:24210
    User-Agent=Fiddler
    http.context.path=/test
    http.context.uri=http://localhost:8089/test
    http.headers={Host=localhost:8089, User-Agent=Fiddler, Keep-Alive=false, Connection=false, Content-Type=application/xml}
    http.method=GET
    http.query.params={}
    http.query.string=
    http.relative.path=
    http.request=/test
    http.request.path=/test
    http.version=HTTP/1.1
  OUTBOUND scoped properties:
    MULE_ENCODING=UTF-8
  SESSION scoped properties:
}
再回头看看 fiddler 抓取的结果,就很容易明白 Inbound Properties, Outbound Properties, Payload 的关系了。











作者:fangxinggood 发表于2013-8-11 23:26:49 原文链接
阅读:97 评论:0 查看评论

相关 [soa mule esb] 推荐:

[SOA] Mule ESB Linux 部署

- - CSDN博客架构设计推荐文章
本文介绍如何在 Linux 上部署 Mule ESB. Mule 是一个以Java为核心的轻量级的消息框架和整合平台,基于EIP(Enterprise Integeration Patterns,由Hohpe和Woolf编写的一本书)而实现的. Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑.

[SOA] Mule ESB 3.x 入门(一)—— 消息流

- - CSDN博客架构设计推荐文章
关于Mule ESB,简单来说Mule接受一个消息,按照某种顺序处理这个消息,这样的处理可导致多种结果. 有时,Mule改变或变换消息返回到原来的消息来源(request-response). 或者,在其原有的基础上改变形式发送到一个或多个第三方(router, transfer). 而在其他一些情况下,如果消息没有达到的具体要求,Mule可以拒绝处理的消息validation, throttling).

文章: Mule ESB 3.3与CloudHub

- - InfoQ cn
MuleSoft最近发布了企业服务总线(ESB)产品Mule ESB 3.3. 在新版本中,除了应用程序集成之外,Mule ESB还拥有了数据集成功能;从而为开发者提供了一个面向本地或云端应用的集成解决方案. 分享云计算在传统IDC、移动互联网、SaaS应用、PaaS平台等领域应用,阿里云开发者大会,免费报名中.

集成ESB实现SOA

- - 企业架构 - ITeye博客
  服务消费者,服务提供者, 服务注册中心(UDDI模型). 由于UDDI模型过于复杂,而服务提供者与消费者点对点的进行协作依赖性大大增强,因此产生演变.    服务代理 -- ESB.    基于ESB总线,使得服务请求者统一入口,而ESB管理服务,使得耦合降低,由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改.

使用Mule Studio开发ESB应用 - Hello World

- - CSDN博客推荐文章
本文介绍如何使用Mule Studio开发一个简单的"Hello World"ESB应用. 第1步 - 下载和安装Mule Studio. 从 www.mulesoft.org下载Mule ESB Community Edition的发布包. 无需安装, 解压至本地硬盘即可使用. 第2步 - 启动Mule Studio.

再谈SOA和ESB总线平台价值

- - 人月神话的BLOG
关于SOA的咨询实施方法论,SOA平台和云平台的融合,SOA咨询方法论和EA企业架构思想的融合在前面很多文章都有谈到. 在多年的SOA咨询和实施中,经常遇到的一个问题就是SOA是不是已经过时了. 而这个问题追溯本源还是客户没有真正理解SOA咨询方法论,SOA组件化架构带来的好处,而是把SOA或ESB理解为了一个简单的接口平台或数据交换平台,如果一开始的思维方式或规划就是错误或偏差的,那么最终效果自然大打折扣.

Mule应用架构:1、关于mule

- - CSDN博客推荐文章
本文介绍Mule结构上的特性,你可以使用它们构建你的Mule应用. l  关于Mule执行单元. Mule ESB提供综合的应用集成,既可服务于小型商业公司,也可用于大型企业. 企业服务总线(ESB)作为Mule的核心功能,即可利于组织内部的内网连接,也利于基于Web的API和其他云资源的外部连接.

SOA资料学习

- - 人月神话的BLOG
从对象到组件,首先可以把对象理解为更细粒度东西,而组件是更加粗粒度的模块,对象更多关注技术,而组件应该更加关注业务. 前面我们谈过技术组件和业务组件,在SOA思想下业务组件化的思想就更加重要. 组件本身而言很简单,南向接口和北向接口,或者再有底座平台支撑. 接口通过服务方式来实现,组件通过OSGI等技术实现高度的解耦和可热插拔性.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

谈ESB服务总线改进

- - 人月神话的BLOG
对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能. 但是RabbitMQ本身更适合做一个企业级的消息系统,其在集群,持久化,高可用性和分布式可扩展性方面往往更加有优势.