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.
