mule in action翻译9 : 2.1 流

 

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支持的和消息交互的细节及相关的一些概念。