This document provides an overview of Mule ESB and messaging with Mule. It discusses: - Mule ESB 3.x, the Mule Management Console, and Mule Studio. - How Mule provides a messaging framework to transfer data between applications as messages with a payload, properties, and optional attachments. - The differences between Mule and a traditional ESB, with Mule only converting data as needed versus requiring an adapter for every application in a traditional ESB.

1. Mule Integration

2. Mule ESB 3.x
Mule Management Console
Mule Studio
Software versions
This class focuses on the version 3.x of the Mule suite.

3. Messaging Framework
 A message is simply a packet of data that can be handled and sent between
applications on a specific channel (also called a queue).
 Many applications don't have the ability to read or process data coming from
another application.
 Mule ESB solves this problem by providing a messaging framework that reads,
transforms, and sends data as messages between applications.
A Mule message is composed of different parts:
 The payload, which is the main data content carried
by the message.
 The properties, which contain the meta information
very much like the header of a SOAP envelope or the
properties of a JMS message.
 If required, a series of attachments that can
accompany the message

4. Mule vs. Traditional ESB
 Difference between Mule and a traditional ESB is that Mule only converts
data as needed.
 Traditional ESB
 Need to create an adapter for every application, connect to the bus and
convert the application's data into a single common messaging format.
 To develop adapter and process message require a lot of time.
 Mule ESB
 Mule eliminates all these efforts.
 Mule increases performance and reduces development time over a
traditional ESB.

5. Messaging styles
One-way
 Receives a message and puts it on a SEDA queue.
 The calling thread returns and the message is processed by the SEDA thread
pool. Nothing gets returned from the result of the call.
 The Mule service must have an asynchronous inbound endpoint.
 If an error occurs it is handled by the Mule server.
 One-Way return types are NullPayloads

6. Messaging styles - contd
Request – Response
 Receives a message and the component returns a message.
 If the component call returns null, then a Mule Message with a NullPayload is
returned.
 If the call method is void the request message is returned.
 The Mule service must have a synchronous inbound endpoint and no outbound
endpoint configured.

7. Messaging styles - contd
6
Synchronous
 A message is now processed synchronously if one of the following is true:
 endpoint is request-response
 A transaction is active
 The message property MULE_FORCE_SYNC is set to TRUE
 Receives a message and the component processes before sending it out on
another endpoint. The request happens in the same thread.
 Mule blocks on the outbound endpoint to wait for a response from the remote
application (if applicable) until the responseTimeout threshold is reached. If no
response is received, it returns null.
 A synchronous call always returns a result, even if there is an outbound
endpoint.

8. 7
Messaging styles - contd
Async Request Response
 This pattern allows the back-end process to be forked to invoke other services
and return a result based on the results of multiple service invocations.
 The Async Reply Router is used to listen on a Reply To endpoint for results.
 Set the reply-to address on the outbound router, and set the <async-reply>
element to listen on that reply endpoint.

9. Message scope
Inbound
 Inbound properties scope will hold the headers/properties sent by the caller
flow/service/external source.
 When a message arrives to a mule endpoint it can contain headers/properties.
Those properties will be placed as inbound properties of the mule message.
 Inbound message properties are read only.

10. Outbound
 Outbound properties scope will contain all the properties that will be deliver
together with the message payload when calling an outbound endpoint.
 When a message is deliver to another endpoint then all the properties in
outbound scope will be sent together with the message as headers.
 After calling an outbound endpoint that returns a response outbound properties
are lost.
Message scope - contd

11. Message scope - contd
 Invocation
 An Invocation property will be present in the invoked flow and will last for all the
flow execution.
 Invocation properties are not propagated to other flows, but will be propagated
if another flow or sub-flow is called using flow-ref.
 Session
 Mule session scope is created when a message enters a mule flow/service and it
will preserved until the message leaves mule.
 Mule session propagation is done only when mule endpoints transport supports
message headers (i.e. JMS, HTTP, VM).
 Any change to those properties within the async flow will not be reflected in the
caller flow.
 Application
 Application properties scope is tied to the application lifecycle
 Application properties are read only.

12. Sample Code – Inbound Scope

13. Sample Code – Outbound Scope

14. Sample Code – Invocation Scope