Message routers are used to control how events are sent and received by components in the system. Mule defines Inbound routers that apply to events as they are received and outbound routers that are invoked when an event is being dispatched.

Quick Reference

Mule provides flexible message routing support for your components. Routing features are based on the enterprise routing requirements described in EIP.
There are a few elements to Mule's routing system -

Inbound Routers

A single event is received via a endpoint and the router controls how and if this event gets routed into the system.

Outbound Routers

Once a message has been processed by a component and outbound router can used to determine which components get the result event.

Response Routers

Are used in request/response scenarios where event 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 to the callee.

Filters

Filters provide the logic by which to invoke a particular router. An example would be the XPathFilter, or PayloadTypeFilter. Filters can be combined using the logic filters, AndFilter, OrFilter and NotFilter.
Not all routers need to use filters but all routers support them. See Filters for information.

CatchAll Strategies

A catch all strategy can be configured on a router and will be invoked if no routing path can be found for the current event. A endpoint can be associated with a catch all strategy so that any events that 'slip through the net' can be caught and routed to a common location.

Configuring Routers

Inbound Router configuration

Inbound routers can be used to control and manipulate events received by a component. Typically, an inbound router can be used to filter incoming event, aggregate a set of incoming events or re-sequence events when they are received. Inbound routers are also used to register multiple inbound endpoints for a component. You can chain inbound routers together, in this scenario each router is matched before the event is dispatched to a mule component. Inbound routers are different to outbound routers in that the endpoint is already known (as the message has already been recieved) so the purpose of the router is to control how messages are given to the component. You can specify a catch-all strategy which will be invoked if any of the routers do not accept the current event. An Inbound Router can be configured on a mule-descriptor element in the mule-config.xml -

<inbound-router>
    <catch-all-strategy className="org.mule.routing.ForwardingCatchAllStrategy">
        <endpoint address="jms://failure.queue"/>
    </catch-all-strategy>
    <router className="org.mule.routing.inbound.SelectiveConsumer">
       <filter expression="(msg/header/resultcode)='success'"
           className="org.mule.routing.filters.xml.JXPathFilter"/>
    </router>
</inbound-router>

There is router configured for this inbound-router. The first is a selective consumer and will accept the event if a nested field in the payload is set to resultcode='success'. If this filter matches, the event will be passed to the component. If either router does not match the Catch all strategy is invoked, which sends all events via its configured endpoint endpoint, in this case a jms queue called 'failure.queue'.

Outbound Router Configuration

Outbound routers are used to control which endpoints are used to send events once an UMO component has finished processing. Message Routers are configured on the compoennt and allow the developer to define multiple routing constraints for any given Event. You can specify a catch-all strategy which wil be invoked if none of the routes accept the current event. An example of an Outbound Message Router is given below -

<outbound-router>
    <catch-all-strategy className="org.mule.routing.ForwardingCatchAllStrategy">
        <endpoint address="jms://default.queue"/>
    </catch-all-strategy>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
       <endpoint address="smtp://[email protected]" transformers="ExceptionToEmail">
           <properties>
               <property name="subject" value="Exception!"/>
               <property name="fromAddress" value="[email protected]!"/>
           </properties>
       </endpoint>
       <filter expectedType="java.lang.Exception"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
    </router>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
        <endpoint address="vm://my.component"/>
        <filter className="org.mule.routing.filters.logic.AndFilter">
            <left-filter expectedType="java.lang.String"
               className="org.mule.routing.filters.PayloadTypeFilter"/>
            <right-filter pattern="the quick brown (.*)"
                className="org.mule.routing.filters.RegExFilter"/>

        </filter>
    </router>
</outbound-router>

This outbound router defines two routers. The first checks to see if the payload type is java.lang.exception, and end the messge via the endpoint; in this case over smtp to [email protected]. There is a transformer on this endpoint ExceptionToEmail which will convert the exception into a javax.mail.Message before sending the event. Note the properties on the endpoint, these will be used to override the Smtp Connector behaviour for this endpoint instance. If the event payload is not an Exception, the second router is invoked which checks to see if the payload type is String and then also checks that the payload matches a regular expression. If both filters match the event is routed to a component listening on vm://my.component. If neither routers match the Catch all strategy is invoked which sends all events to a jms queue called 'default queue'.

Matching all Routers

It is possible to configure an outbound router to invoke all of the matching routers, rather than just the first. For example, in the situation where you always want to send a confirmation of a deposit back to the original depositor, and, if the deposit was above $100,000, send a notification message to the 'high net worth client manager' for possible follow-up, you can utilise the matchAll property on the router definition as follows:

<outbound-router matchAll="true">
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
        <endpoint address="jms://deposit.queue"/>
    </router>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
        <endpoint address="endpoints="jms://large.deposit.queue"/>
  <filter expression="deposit/amount >= 100000"
            className="org.mule.routing.filters.xml.JXPathFilter"/>
    </router>
    </router>
</outbound-router>

Here, the first router will always match as there is no filter on it and the second router will only match of the deposit amount is >= $100000 - if this is the case then both routers will be invoked.

Response Router Configuration

Response routers can be used to join forked tasks in a request response call. In fact you would only use a response router with components that use synchronous calls (as there is no response when dispatching an event asynchronously). Mule provides a ResponseAggregator router that can be used in conjunction with a Message Splitter or Recipient List router to aggregate events before returning a response.

<response-router>
    <endpoint address="jms://bank.quotes"/>
    <router className="org.mule.samples.loanbroker.routers.BankQuotesResponseAggregator"/>
</response-router>

The endpoint is the address that responses should be sent to be processed. The router in this case is responsible for aggregating Bank quotes into a single quote for the customer. Consider the LoanBroker component configuration below-

<mule-descriptor name="LoanBroker"
    implementation="org.mule.samples.loanbroker.SyncLoanBroker">
    <inbound-router>
        <endpoint address="vm://Loan.Requests"/>
    </inbound-router>

    <response-router>
        <endpoint address="jms://Loan.Quotes"/>
        <router className="org.mule.samples.loanbroker.routers.BankQuotesResponseAggregator"/>
    </response-router>

    <outbound-router>
        <router className="org.mule.routing.outbound.StaticRecipientList">
            <reply-to address="jms://Loan.Quotes"/>
            <filter expression="recipients!=null"
                className="org.mule.routing.filters.MessagePropertyFilter"/>
        </router>
    </outbound-router>
</mule-descriptor>

Don't worry too much about the filters and routers as these are descibed in detail below. What this configuration demonstrates is that our Loan Broker will receive requests from vm://Loan.Requests and will dispatch multiple requests to different banks via the outbound router. The bank endpoints are defined in a List called 'recipients' that is a property on the outbound message (See the Loan Broker Example for more information). The important setting on the outbound router is the <reply-to> endpoint, this tells Mule to route all responses to the jms://Loan.Quotes endpoint which is the endpoint that the response router is listening on. When all responses are received the BankQuotesResponseAggregator selects the cheapest quotes and returns it. Mule then handles returning this back to the callee. The <reply-to> Endpoint is applied to the next component invoked, i.e. if component1 dispatches to component2 and component1 has an outbound router with a reply-to endpoint, component2 will send the results of its invocation to the reply-to endpoint.

Response Transformers

Sometimes you will want to transform response event without doing any other work on the response. To do this just set the transformers attribute on the response router without any other routing configuration.

<response-router transformers="OrderConfirmationToXml XmlToWebPage"/>

Mule Inbound Routers

The following sections describe each Mule inbound router and how to configure them.

Idempotent Receiver

An IdempotentReceiver is an Inbound router that ensures only unique messages are received by a component. It ensures that each message is unique by checking and storing the unique id of each message it receives. Note that this unique id often comes from the underlying technology and that some endpoints do not support unique ids. If the endpoint being used doesn't support unique ids an exception will be thrown.

There is a simple Idempotent receiver implementation provided at org.mule.routers.inbound.IdempotentReceiver. The default Implementation uses a simple file-based mechanism for storing message ids, but this class can be extended to use a database to store the ids.

Configuration

<inbound-router>
    <router className="org.mule.routing.inbound.IdempotentReceiver">
        <properties>
            <property name="disablePersistence" value="false"/>
            <property name="storePath" value="./idempotent"/>
       </properties>
    </router>
</inbound-router>

disablePersistence - Determines whether received message ids are stored to disk so that the router can remember state between restarts. The default value is false;

storePath - Determines where to store the received ids file. The mule working directory is set in the Muleconfiguration.setWorkingDir(...). The default working directory for is ./.mule. The file created will be in the form of muleComponent_<componentName>. The default value for this property is ./.mule/idempotent/.

Selective Consumer

A selective consumer is an Inbound Router that can apply one or more filters to the incoming event payload. If the filters match the event will get forwarded to the component otherwise the event will get forwarded to the catch-all strategy on the router. If not catch-all is configured the event is ignored and a warning is logged.

Configuration

<inbound-router>
    <catch-all-strategy className="org.mule.routing.ForwardingCatchAllStrategy">
       <endpoint address="jms://topic:error.topic"/>
    </catch-all-strategy>
    <router className="org.mule.routing.inbound.SelectiveConsumer">
        <filter expression="msg/header/resultcode = 'success'"
           className="org.mule.routing.filters.xml.JXPathFilter"/>
    </router>
</inbound-router>

There are no properties associated with this router, however see Filters for more information about the how filters can be used and what filters are available.

Note that by default the filter is applied to the event payload after the transformers configured for the inbound endpoint are applied to the event. There may be situations where the developer may need to execute filters on the event payload without any transformation being applied. You can set the transformFirst property on this router to control if transformations are applied.

<inbound-router>
    <catch-all-strategy className="org.mule.routing.ForwardingCatchAllStrategy">
       <endpoint address="jms://topic:error.topic"/>
    </catch-all-strategy>
    <router className="org.mule.routing.inbound.SelectiveConsumer">
        <filter expression="msg/header/resultcode = 'success'"
           className="org.mule.routing.filters.xml.JXPathFilter"/>
        <properties>
            <property name="transformFirst" value="false"/>
        </properties>
    </router>
</inbound-router>

Aggregator

The Aggregator pattern stipulates that two or more messages are combined into a single result message. Mule provides an abstract implementation that has a template method that actually does the message aggregation. A common use of the aggregator router is to combine the results of multiple requests such as "ask this set of vendors for the best price of X".

The Aggregator is based on the Selective Consumer so filters can also be applied to messages.

Configuration

<inbound-router>
    <router className="org.mule.routing.inbound.CorrelationAggregator">
        <filter expectedType="org.foo.some.Object"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
        </router>
</inbound-router>

The CorrelationAggregator can be used to match messages with a given CorrelationId. Correlation Ids are set on messages when they are dispatched for certain outbound routers such as the Recipient List and Message Splitter routers. These messages can be aggregated back together again using the CorrelationAggregator router.

You can easily write custom Aggregator routers to aggregate on some other criteria if your messages. There is an AbstractEventAggregator that provides a thread-safe implementation for custom Aggregators.

Resequencer

The Resequencer Router will hold back a set of messages, re-order them and send them to the target component in the correct sequence. A java.util.Comparator is used to sort the events. This router is based on the Selective Consumer which means that filters can be applied to the incoming events.

Configuration

<inbound-router>
    <router className="org.mule.routing.foo.SimpleEventResequencer">
        <filter expression="msg/header/resultcode = 'success'"
           className="org.mule.routing.filters.xml.JXPathFilter"/>
        <properties>
            <property name="comparator"
                value="org.mule.routing.foo.EventPayloadComparator"/>
            <property name="eventThreshold" value="5"/>
        </properties>
    </router>
</inbound-router>

The EventPayloadComparator is used to re-order the events. If a comparator is not set the events will not be resequenced.

There is also a CorrelationEventResequencer that will reseguence a group of messages (grouped by their correlation Id) depending on the order the messages were sent. This is useful where you configure a Message Splitter to send out multiple events and then you want to process all the split message parts in a particular order.

<inbound-router>
    <router className="org.mule.routing.inbound.CorrelationEventResequencer"/>
</inbound-router>

There is no need for any further configuration as the router uses standard properties on the MuleMessage.

Forwarding Consumer

This router allows for events to be forwarded to an outbound endpoint without first being processed by a component. It essentially acts as a bridge between an inbound and an outbound endpoint. This is useful in situations where the developer does not need to execute any logic on the inbound event but does need to foward it on to a component residing on another destination (i.e. a remote Mule node or application) over the network.

Configuration

<mule-descriptor name="FileReader"
    inboundEndpoint="file:///temp/myfiles/in"
    outboundTransformer="ObjectToByteArray"
    outboundEndpoint="tcp://192.168.0.6:12345"
    implementation="org.mule.components.simple.NullComponent">
    <inbound-router>
        <router className="org.mule.routing.inbound.ForwardingConsumer"/>
    </inbound-router>
</mule-descriptor>

When the event is triggered by a file on the local file system becoming availiable the event is automatically forwarded via tcp to 192.168.0.6. Notice that there is a outboundTransfrmer configured. This will be used to transform the event's payload before it is dispatched over tcp. Also, the implementation of this component is the NullComponent. This component doesn't do anything as is just acts as a place holder. However, you could mix and match the routers so that some events are forwarded while others are processed by the component.

The Forwarding Consumer extends the Selective Consumer so you can configure filters on this router.

BridgeComponent

As of Mule 1.1 the Forwarding consumer can be automatically configured using the BridgeComponent. This is a component that automatically configures the Forwarding consumer and replaces the need for the NullComponent in the above example. The same example using the the BridgeComponent would look like -

<mule-descriptor name="FileReader"
    inboundEndpoint="file:///temp/myfiles/in"
    outboundTransformer="ObjectToByteArray"
    outboundEndpoint="tcp://192.168.0.6:12345"
    implementation="org.mule.components.simple.BridgeComponent">
</mule-descriptor>

Mule Outbound Routers

The following sections describe each Mule outbound router and how to configure them. Outbound routers can be more complex to configure as they allow different routing paths that can be selected depending on the logic defined in one or more filters.

Content Based Router

Content based routing is the term used for routing events based on the event contents. Mule currently supports content based routing using the Filtering Outbound Router, but by Mule v1.0 JSR-94 rules based routing will be possible.

Filtering Outbound Router

A content based router uses filters to determine whether the content of the event matches a particular criteria and if so will route the event to one or more endpoints configured on the router.

All Mule outbound routers extend FilteringOutboundRouter which means you can always apply a filter to an outbound router.

Configuration

<outbound-router>
    <catch-all-strategy className="org.mule.routing.ForwardingCatchAllStrategy">
        <endpoint="jms://error.queue"/>
    </catch-all-strategy>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
       <endpoint address="smtp://[email protected]"/>
       <filter expectedType="java.lang.Exception"
          className="org.mule.routing.filters.PayloadTypeFilter"/>
    </router>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
        <endpoint address="jms://string.queue"/>
        <filter className="org.mule.routing.filters.logic.AndFilter">
            <left-filter expectedType="java.lang.String"
                className="org.mule.routing.filters.PayloadTypeFilter"/>
            <right-filter pattern="the quick brown (.*)"
                className="org.mule.routing.filters.RegExFilter"/>
        </filter>
    </router>
</outbound-router>

The filter is applied to the event payload before any transformers are applied to the event. There may be situations where the developer may need to transform the event before the filter is applied. You can set a transformer on this router that will be applied to the event before the filter.

<outbound-router>
    <router className="org.mule.routing.outbound.FilteringOutboundRouter">
       <endpoint address="smtp://[email protected]"/>
       <filter expectedType="java.lang.Exception"
          className="org.mule.routing.filters.PayloadTypeFilter"/>
       <properties>
           <property name="transformer" value="aTransformer"/>
       </properties>
    </router>
</outbound-router>

Recipient List

the Recipient list router can be used to send the same event to multiple endpoints over the same endpoint or to implement routing-slip behaviour where the next destination for the event is determined from the event properties or payload. Mule provides an abstract Recipient list implementation org.mule.routing.outbound.AbstractRecipientList that provides a thread-safe base for specialised implementations. Mule also provides a Static recipient list that takes a configured list of endpoints from the current event or statically declared on the endpoint.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.StaticRecipientList">
       <filter expectedType="javax.jms.Message"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
       <properties>
           <list name="recipients">
               <entry value="jms://orders.queue"/>
               <entry value="jms://tracking.queue"/>
           </list>
       </properties>
    </router>
</outbound-router>

ReplyTo

You can use the reply-to endpoint of the outbound router to ensure all messages sent got sent back to the same destination.

<outbound-router>
    <router className="org.mule.routing.outbound.StaticRecipientList">
       <reply-to address="vm://component4"/>
       <filter expectedType="javax.jms.Message"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
       <properties>
           <list name="recipients">
               <entry value="jms://orders.queue"/>
               <entry value="jms://tracking.queue"/>
           </list>
       </property>
    </router>
</outbound-router>

This configuration will first check that the payload type is a Jms Message and will then send the message to the orders.queue and tracking.queue.

Multicasting Router

The Multicasting router can be used to send the same event over multiple endpoints. When using this router care must be taken to configure the correct transformers on the endpoints to handle the event source type.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.MulticastingRouter">
       <endpoint address="jms://test.queue" transformers="StringToJmsMessage"/>
       <endpoint address="http://10.192.111.11" transformers="StringToHttpClientRequest"/>
       <endpoint address="tcp://10.192.111.12" transformers="StringToByteArray"/>
       <filter expectedType="java.lang.String"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
    </router>
</outbound-router>

Remember that care should be taken to ensure that the message being routed is transformed to a format that the endpoint understands.

ReplyTo

Again, you can use the reply-to property of the outbound router to ensure all messages sent got sent back to the same destination.

<outbound-router>
    <router className="org.mule.routing.outbound.MulticastingRouter">
       <endpoint address="jms://test.queue" transformers="StringToJmsMessage"/>
       <endpoint address="http://10.192.111.11" transformers="StringToHttpClientRequest"/>
       <endpoint address="tcp://10.192.111.12" transformers="StringToByteArray"/>
       <reply-to address="vm://component4"/>
       <filter expectedType="java.lang.String"
           className="org.mule.routing.filters.PayloadTypeFilter"/>
    </router>
</outbound-router>

Exception Based Router

The Exception Based router can be used to send an event over an endpoint by selecting the first endpoint that can connect to the transport. This can be useful for setting up retries, when the first endpoint fails the second will be invoked and if that fails it will try the third endpoint, and so on. Note, it will override the endpoint mode to synchronous while looking for a successful send, and will resort to using the endpoint's mode for the last item in the list.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.ExceptionBasedRouter">
       <endpoint address="tcp://10.192.111.10:10001" />
       <endpoint address="tcp://10.192.111.11:10001" />
       <endpoint address="tcp://10.192.111.12:10001"/>
    </router>
</outbound-router>

Message Splitter

A message splitter can be used to breakdown an outgoing message into parts and dispatch those parts over different endpoints configured on the router. Mule provides and abstract implementation of a message splitter org.mule.routing.outbound.AbstractMessageSplitter that provides thread-safe base implementation with the necessary logic for routing the event allowing concrete implementations define how the message is split.

Configuration

<outbound-router>
    <router className="org.foo.ConcreteMessageSplitter">
       <endpoint address="vm://component1"/>
       <endpoint address="vm://component2"/>
       <endpoint address="vm://component3"/>
    </router>
</outbound-router>

Note as with all router configurations you can define properties elements to set bean properties on the router. For example, you may want to define a list of XPath expressions that would be used to extract the different message parts. See Configuring Properties for more information.

By default the AbstractMessageSplitter sets a Correlation Id and Correlation Sequence to the outbound events so that inbound routers such as the Aggregator or Resequencer are able to resequence or combine the split messages.

ReplyTo

You can use the reply-to property of the outbound router to ensure all messages sent got sent back to the same destination.

<outbound-router>
    <router className="org.foo.ConcreteMessageSplitter">
       <endpoint address="vm://component1"/>
       <endpoint address="vm://component2"/>
       <endpoint address="vm://component3"/>
       <reply-to address="vm://component4"/>
    </router>
</outbound-router>

Filtering List Message Splitter

This router is an implementation of Message Splitter that accepts a list of objects that will be routed to different endpoints. The actual endpoint used for each object in the list is determined by a filter configured on the endpoint itself. If the endpoint's filter accepts the object the endpoint will be used to route the object.

The router configuration below expects the message payload to be a java.util.List and will route objects in the list that are of type com.foo.Order, com.foo.Item and com.foo.Customer. The router will allow any number and combination of these objects.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.FilteringListMessageSplitter">
        <endpoint address="jms://order.queue">
           <filter expectedType="com.foo.Order" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <endpoint address="jms://item.queue">
           <filter expectedType="com.foo.Item" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <endpoint address="jms://customer.queue">
           <filter expectedType="com.foo.Customer" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <filter expectedType="java.util.List" className="org.mule.routing.filters.PayloadTypeFilter"/>
    </router>
</outbound-router>

Note that there is also a filter on the router itself that ensures that the message payload received is of type java.util.List. If there are objects in the list that do not match any of the endpoint filters a warning will be written to the log and processing will continue. To route any non-matching object types to another endpoint just add the endpoint at the end of the list without a filter.

Filtering Xml Message Splitter

Analogous to the above, but operating on XML documents. Supported payload types are:

• org.dom4j.Document objects
• byte[]
• java.lang.String

If no match found, it will be ignored (logged at the WARN level).

The router will split the payload into nodes based on the splitExpression property. The actual endpoint used for each object in the list is determined by a filter configured on the endpoint itself. If the endpoint's filter accepts the object the endpoint will be used to route the object.

The router can optionally perform a validation against an external XML Schema document. Point externalSchemaLocation to XSD file in your classpath. Note in this case you override whatever schema document you declare in XML header.

Each part returned is actually returned as a new DOM4J document.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.FilteringXmlMessageSplitter">
        <endpoint address="vm://order">
           <filter expectedType="com.foo.Order" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <endpoint address="vm://item">
           <filter expectedType="com.foo.Item" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <endpoint address="vm://customer">
           <filter expectedType="com.foo.Customer" className="org.mule.routing.filters.PayloadTypeFilter"/>
        </endpoint>
        <filter expectedType="org.dom4j.Document" className="org.mule.routing.filters.PayloadTypeFilter"/>
        <properties>
           <property name="splitExpression" value="/root/nodes"/>
           <property name="validateSchema" value="true"/>
           <property name="externalSchemaLocation" value="/com/example/TheSchema.xsd"/>
        </properties>
    </router>
</outbound-router>

Chaining Router

The Chaining router can be used to send the event through multiple endpoints using the result of the first invocation as the input for the next. This can be useful where you want to send the results of a synchronous request-response invocation, say, a Web Services call, to a jms queue.

Configuration

<outbound-router>
    <router className="org.mule.routing.outbound.ChainingRouter">
         <endpoint address="axis:http://localhost:8081/services/xyz?
           method=getSomething"/>
         <endpoint address="jms://something.queue"
            transformer="SomethingToJmsMessage"/>
    </router>
</outbound-router>

Using Replyto Endpoints

All outbound routers can have a <reply-to> endpoint that defines where the event should be routed to after the recipient of the event being dispatched has finished with it. The <reply-to> Endpoint is applied to the next component invoked, i.e. if component1 dispatches to component2 and component1 has an outbound router with a reply-to endpoint, component2 will send the results of its invocation to the reply-to endpoint.

The <reply-to> endpoint can be valid Mule Endpoint URI and will be sent with the outgoing message. If the underlying transport supports the notion of replyTo, such as Jms, this will be utilised for replyTo endpoints that use Jms.