This document provides an overview and agenda for a Mule Integration Workshop. It discusses Mule ESB 3.x, the Mule messaging framework, differences between Mule and traditional ESBs, messaging styles in Mule including one-way, request-response, synchronous, and asynchronous request-response, and message scopes in Mule including inbound, outbound, invocation, session, and application scopes. Code samples are also provided to demonstrate inbound, outbound, and invocation scopes.

1. Mule Integration Workshop
Mule Messages

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. Agenda
 Messaging framework
 Mule vs. Traditional ESB
 Messaging styles
 Message scope/properties

4. 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

5. 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.

6. 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

7. 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.

8. Messaging styles - contd
7
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.

9. 8
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.

10. 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.

11. 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

12. 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.

13. Sample Code – Inbound Scope

14. Sample Code – Outbound Scope

15. Sample Code – Invocation Scope

16. Thank you