mule in action翻译9 : 2.1 流
2.1 流
流是mule配置中最重要的元素。
一般流的起点是一个消息源,随后是一系列消息处理器。这些处理器以流元素的形式串联起来。
向流中添加处理器时,没有处理器的类型的限制,也没有顺序的限制。
来看1.4.2中的产品注册的流。
清单2.1中 稍微修改了这个流,添加了个logger元素。
Listing 2.1 The product registration flow, now with logging
<flow name="product-registration"> <http:inbound-endpoint address="http://api.prancingdonkey.com/products" method="POST" /> <byte-array-to-string-transformer /> <logger level="INFO" category="products.registration" /> <jms:outbound-endpoint queue="products" /> </flow>
Mule Studio中的流 如图2.1。
那个是消息源?哪些是消息处理器?看图2,2
图2.2中采用椭圆表示消息源,矩形表示消息处理器,本书其余部分示图遵此惯例。
在流中 ,消息源生成消息然后以从上到下的顺序被消息处理器处理。
顺着上图箭头很容易的看明白,消息是一步步被处理的。
在稍后章节你会明白消息路线是可以被一些消息处理器改变的,
比如路由消息处理器允许你控制消息执行路线。
若流中的一个消息处理器返回了null ,处理将立即终止。
一般的转换器和组件不会返回null,只是可能返回nul的payload,这不会影响执行流程。
mule提供了特殊的流元素,叫 配置方式,6.2节详解。
到此为止我们只考虑了流的一个方向:自上而下。这是消息进入mule并被处理的路线。
但返回的路呢?来看流如何处理响应。
2.1.1 响应阶段
理解mule的响应阶段非常重要。
首先要明白响应阶段是隐含的;它总会出现,默认是由请求阶段的终点生成的回应消息构成。
尽管不明显但listing 2.2 中的流是有响应阶段的
Listing 2.2 A flow with an implicit response phase
<flow name="accountService"> <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8080" path="services" /> <jersey:resources> <component class="com.prancingdonkey.resource.Accounts" /> </jersey:resources> </flow>
Mule Studio展示的响应阶段表明显。见图2.3
底部向左的箭头表示响应阶段。
用来组成响应的 payload和属性,来自于流终点处理后的mule消息。
当流包含分支时 可能包含多个终点,这时是在某分支的终点生成响应。
通过一个特殊的配置元素“response”,可以控制响应阶段。它是只在
响应阶段才被调用的消息处理器。
需要注意的是这些“response”信息处理器是按照相反的顺序被调用的--从下往上,
或者更精确的说是从流的终点向起点的顺序。
看listing 2.3 的配置,如果我发出一个payload内容是“hello”的消息,最后反会的将是什么结果?
Listing 2.3 A flow with elements explicitly in the response phase
<flow name="explicitResponse"> <vm:inbound-endpoint path="input" exchange-pattern="request-response"> <response> <append-string-transformer message=" web" /> </response> </vm:inbound-endpoint> <response> <append-string-transformer message=" wide" /> </response> <append-string-transformer message=" world" /> </flow>
答案是 “hello world wide web” 。
string appender 按照下面顺序被调用:请求阶段追加了“world”,响应阶段追加了“wide”和“web”。
注意我们是如何在主flow 和 endpoint中添加response元素的。
response元素运行你执行所有必要的处理,以保证返回给流的调用者想要的结果。
为了处理有组件或outbound endpoint产生的payload,你已经在响应阶段执行了
具有代表性的消息转换器。
最后,如果 响应是由reply-to路由返回的,则响应阶段会被忽略。这种情况下,请求阶段的
终点的消息状态作为响应返回。消息处理器会被执行,但他们的处理结果将被丢弃。
2.1.2 子流
复制粘贴是软件开发的祸根。
如果你发现你的流有很多共同的东西 ,你应该提取出这些 共同的消息处理器片段,以实现重用。
子流,就是因此产生的。
子流的行为和标准的流一样,只是它没有消息源。当显示的调用“ flow-ref”元素时 ,它才进行消息处理。
你可以把 子流看成一个包含了一组预定义的消息处理器的“宏”,你可以随时调用它。
当一个流调用子流时,整个mule 消息和上下文消息都会传递为子流。子流的处理结果的整个的上下文消息也会传递给
主流。实际上子流的消息处理器的处理方式和主流中的一样。
另外注意,调用线程去执行子流。
一个有名字的链 一个子流是一个处理器链,它有自己的名字,可以独立存在于主流之外, 可以被任意流调用。
它和你的办公套件中的 “宏“非常的类似。
listing 2.4 展示了Prancing Donkey 公司是如何使用子流作为通用的转换器链。列表中你看到他们是如何在子流、
中使用一组转换器并在其它两个不用的流中进行重用的。流经这两个流的消息都会被这组转换器转换,看起来
他们好像是直接配置在这两个流中的。
Listing 2.4 Using a subflow to share a common set of transformers
<sub-flow name="legacyAdapterSubFlow"> <mulexml:xslt-transformer xsl-file="v1_to_v2.xsl" /> <mulexml:xml-to-object-transformer /> </sub-flow> <flow name="mainFlow1"> <http:inbound-endpoint host="localhost" port="8080" path="v1/email" /> <flow-ref name="legacyAdapterSubFlow" /> <component class="com.prancingdonkey.service.v2.EmailGateway" /> </flow> <flow name="mainFlow2"> <jms:inbound-endpoint queue="v1.email" /> <flow-ref name="legacyAdapterSubFlow" /> <component class="com.prancingdonkey.service.v2.EmailGateway" /> </flow>
图2.4 是对上面代码的 表示
这是非常简单的。
你经常会遇到需要重用的情况,但是又不能清晰的抽取出一组处理器来重用。
请记住流变量(invocation-scoped message properties)可以帮助重用,因为它们可以作为流控制变量。
举例说明,请看 listing 2.5的子流。
流变量”valid“决定了如何选择下一步。每个父流程都必须基于正确的规则来设置好这些消息属性,以使能正确路由。
Listing 2.5 Flow variables can be used to parameterize a subflow.
<sub-flow name="requestDispatcher"> <choice> <when expression="#[valid]"> <vm:outbound-endpoint path="valid.request.handler" exchange-pattern="request-response" /> </when> <otherwise> <vm:outbound-endpoint path="invalid.request.handler" exchange-pattern="request-response" /> </otherwise> </choice> </sub-flow>
如果你有使用mule 3之前版本的经验,你必定会使用很多VM endpoints 把services捆起来。
一直使用子流或者 使用VM endpoints把流集中起来 ,这样做正确吗?
两种方式一个很大的区别是子流程会传递所有的消息属性,
而VM endpoint 只交换作用域内的需要复制的属性。
另一方面,使用VM队列去连接流降低了耦合度,这在某种情况下是很有用的。
mule提供另外一种共享流的方式叫做 私有流。来看子流和私有流有什么不同。
2.1.3 私有流
私有流是另一种类型的可重复使用的流量,非常类似于子流,但它在线程和异常方面处理不同。
使用私有流而非子流的主要原因 需要设置与调用流不用的异常处理。另外一个原因是,
子流在运行时不是具体化的,没有特定的统计数据或调试属性不能进行独立的控制和监控。
而私有流提供了这些东西。
如上一节所言,调用一个子流时,执行的行为好像就在这些处理器就在”调用流程“
(--这里相对于被调用而言)之中一样。这种解耦导致私有流可以定义自己的消息处理和错误处理。
那么,一个私人流是什么样子?基本上它只是一个普通的流,但没有任何消息来源。
为了说明这一点,让我们重新使用Prancing Donkey公司的子流 把消息从旧格式转换
到一个新格式(见清单2.6)。
消息的一小部分转换失败,然后他们决定配置本地的异常行策略,以便把失败的消息发送
到JMS队列中供以后分析和再加工。
Listing 2.6 Using a private flow to define a local exception strategy
<flow name="legacyAdapterPrivateFlow" processingStrategy="synchronous"> <mulexml:xslt-transformer xsl-file="v1_to_v2.xsl" /> <mulexml:xml-to-object-transformer /> <catch-exception-strategy> <jms:outbound-endpoint queue="legacyAdapter.failures" /> </catch-exception-strategy> </flow>
处理策略 上例中我们在一个私有流中配置了一个属性叫”processingStrategy“ ,这不是必须的,
但我们强烈建议在你所有的私有流进行这个配置。设置成synchronous还是asynchronous,要取决于
调用流。(若调用流希望私有流生成响应配置成synchronous)
如果你没有指定处理策略,mule将根据流入事件的同步性来选择一个。one-way endpoints产生的事件
将按照异步来执行,即使 调用流希望私有流返回响应。第11章深入讨论处理策略。
同样 ,我们强烈建议使用 flow-ref 封装进行异步处理私有流的 <async> 。
在Mule Studio中 需要注意的一点是私有流和子流的区别是私有流名字前的”灰色“的标签,
就是图2.5显示 flow字样的部分。
到目前为止我们只是关注流和控制,这使我们大致了解mule内部消息的传输。
现在我们来看mule支持的和消息交互的细节及相关的一些概念。
相关推荐
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 ESB(企业服务总线)的入门教程,旨在帮助读者系统地学习和理解这一强大的集成平台。Mule ESB是开源领域中的一个重量级选手,常用于构建灵活、可扩展的企业级集成解决方案。这...
《Mule in Action》一书深入探讨了Mule——一个轻量级消息框架与高度分布式的对象代理系统,为读者提供了全面的理论与实践指导。本书由David Dossot和John D'Emic共同撰写,旨在帮助开发者掌握Mule的核心功能与配置...
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 in Action》第二版是一本详细介绍Mule ESB(Enterprise Service Bus)这一著名开源框架的书籍。该书由David Dossot、John D...
《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支持多种消息...
根据提供的文档信息,本文将对"Mule 2.1.1 Getting Started"这一主题进行深入解析,主要包括Mule的基本概念、架构理解、消息传递机制、环境集成等方面,并通过具体示例来帮助理解如何使用Mule。 ### Mule 2.1.1简介...
Spring Boot模块扩展... 将此依赖项添加到您的应用程序pom.xml <groupId>com.kloudtek.mule.module.springboot</groupId><artifactId>mule-springboot-module</artifactId><version>1.0.0</version>ule子弹簧引导模块