Lesson Four: Introduction to Message Routing

This lesson provides an introduction to message routing and describes when to use the different message styles.

Overview

Message routers control how messages are routed among the services in your Mule ESB application. Following is a description of the key concepts:

• Inbound routers control how a service handles incoming messages, such as selectively consuming only those messages that meet specific criteria or grouping messages together that share a group ID before forwarding them on.

• Outbound routers control how a message is dispatched after the service has processed it, such as sending it to a list of recipients or splitting up the message and sending the parts to different endpoints.

• Asynchronous reply routers are used in request/response scenarios where message traffic is triggered by a request and the traffic needs to be consolidated before a response is given. The classic example of this is where a request is made and tasks are executed in parallel. Each task must finish executing and the results processed before a response can be sent back.

• Catch-all strategies are invoked if no routing path can be found for the current message. An inbound or outbound endpoint can be associated with a catch-all strategy so that any orphaned messages can be caught and routed to a common location.

• Filters provide the logic used to invoke a particular router. Filters can be combined using the logic filters AndFilter, OrFilter, and NotFilter. Not all routers need to use filters, but all routers support them.

Selecting a Message Style

When wiring your Mule services together, new users sometimes get confused about when to use an outbound router and when it's sufficient to simply get a reply. Following is a description of the message styles you can use in Mule.

Asynchronous

If you simply want to put a message on a SEDA queue after processing it, and no response to the caller is required, you can use the asynchronous message style.

For example:

<model name="Asynchronous_Message_Pattern">
  <service name="AsynchronousService">

    <inbound>
      <jms:inbound-endpoint queue="test.in" synchronous="false"/>
    </inbound>

    <component class="org.myorg.WidgetHandler" />

    <outbound>
      <pass-through-router>
        <jms:outbound-endpoint queue="test.out">
      <pass-through-router> 
    </outbound>

  </service>
</model>

Request-Response

In simple scenarios that require a response, a service receives a request on a synchronous inbound endpoint, processes the request, and then sends it back to the caller as a reply. For example, if a user enters a value in an HTML form, and you want to transform that value and display the results in the same page, you can simply configure a synchronous inbound endpoint on the service that does the transformation. This scenario does not use an outbound router. This is the request-response message style.

For example:

<model name="Request-Response_Message_Pattern">
  <service name="SynchronousService">

    <inbound>
      <http:inbound-endpoint host="localhost" port="8080" path="/mule/services" synchronous="true"/>
    </inbound>

    <component class="org.myorg.WidgetHandler" />

  </service>
</model>

Synchronous

If you need to pass the message to a second service for additional processing, you would configure an outbound router on the first service to pass the message to the second service. After the second service processes the message, the first service sends it back to the caller as a reply. Note that setting the synchronous inbound endpoint on the first service means that the message is treated synchronously throughout all subsequent services, so you do not need to set the synchronous flag on the second service. This is the synchronous message style.

For example:

<model name="Synchronous_Message_Pattern">
  <service name="SynchronousService">
    <inbound>
      <jms:inbound-endpoint queue="test.in" synchronous="true"/>
    </inbound>

    <component class="org.myorg.WidgetHandler" />

    <outbound>
      <chaining-router>
        <jms:outbound-endpoint queue="test.out"/>
      </chaining-router>
    </outbound>
  </service>

  <service>
    <inbound>
      <jms:inbound-endpoint queue="test.out"/>
    </inbound>

    <component class="org.myorg.WidgetPackager" />

  </service>
</model>

Asynchronous Request-Response

In the most complex scenario, you can enable request-response messaging and allow the back-end process to be forked to invoke other services, returning a reply asynchronously based on the results of multiple service invocations. You can set the inbound endpoint's synchronous flag to false, since the response will be handled by the asynchronous reply router, unless you also want to send a response to the caller. This is the asynchronous request-response message style.

In the following example, a request comes in on an HTTP endpoint, is broadcast to two endpoints using the Multicast router, and the results are sent asynchronously to a JMS endpoint.

<model name="Async_Request-Response_Message_Pattern">
  <service name="AsyncRequestResponseService">
    <inbound>
      <http:inbound-endpoint host="localhost" port="8080" path="/mule/services" synchronous="false"/>
    </inbound>

    <component class="org.myorg.WidgetHandler" />

    <async-reply timeout="5000">
      <collection-async-reply-router/>
      <jms:inbound-endpoint queue="reply.queue"/>
    </async-reply>

    <outbound>
      <multicasting-router>
        <reply-to address="jms://reply.queue"/>
        <jms:outbound-endpoint queue="service1" synchronous="false"/>
        <jms:outbound-endpoint queue="service2" synchronous="false"/>
      </multicasting-router>
    </outbound>
  </service>
</model>

Summary

This lesson described the different message styles you can use. For complete information, see Mule Messaging Styles in the Mule User's Guide.

Now that you understand which message styles to use for routing in different scenarios, Lesson Five describes several routers you can use for achieving finer control over message routing.