Introduction to Mule ESB

1. Module 1:
Introduction to Mule ESB

2. Agenda
What ?
Why?
How?
Where?

3. Point to Point Integration

4. Enterprise Service Bus
ESB

5. Enterprise Service Bus
 An enterprise service bus (ESB) implements a communication system between
mutually interacting software applications in a service-oriented architecture (SOA).
 All customer services communicate in the same way with the ESB: the ESB
translates a message to the correct message type and sends the message to the
correct consumer service.
 Hide Complexity
 Simplify access
 Canonical pattern Support
 Integration driven by business requirements not by available technology

6. Features of ESB
 Route messages between services
 Monitor and control routing of message exchange between services
 Resolve contention between communicating service components
 Control deployment and versioning of services
 Marshal use of redundant services
 Provide commodity services like event handling, data transformation and mapping,
message and event queuing and sequencing, security or exception handling,
protocol conversion and enforcing proper quality of communication service

7. Mule ESB
 Mule, the runtime engine of Anypoint Platform, is
 lightweight Java-based enterprise service bus (ESB) and integration platform
 Allows developers to connect applications together quickly and easily, enabling them to
exchange data.
 It enables easy integration of existing systems, regardless of the different technologies
that the applications use, including JMS, Web Services, JDBC, HTTP, and more.
 The ESB can be deployed anywhere, can integrate and orchestrate events in real time or
in batch, and has universal connectivity.

8. Why Mule?
 Mule has powerful capabilities that include:
 Service creation and hosting — expose and host reusable services, using the ESB
as a lightweight service container
 Service mediation — shield services from message formats and protocols,
separate business logic from messaging, and enable location-independent service
calls
 Message routing — route, filter, aggregate, and re-sequence messages based on
content and rules
 Data transformation — exchange data across varying formats and transport
protocols

10. Advantages over competitors
 Mule components can be any type you want. can easily integrate anything from a "plain
old Java object" (POJO) to a component from another framework.
 Mule and the ESB model enable significant component reuse. (No Programming or
mule specific code changes are required)
 Messages can be in any format from SOAP to binary image files. Mule does not force
any design constraints on the architect, such as XML messaging or WSDL service
contracts.
 You can deploy Mule in a variety of topologies, not just ESB. Because it is lightweight
and embeddable, Mule can dramatically decrease time to market and increases
productivity for projects to provide secure, scalable applications that are adaptive to
change and can scale up or down as needed.
 Mule's stage event-driven architecture (SEDA) makes it highly scalable. A major financial
services company processes billions of transactions per day with Mule across thousands
of Mule servers in a highly distributed environment.

11. Mule Message Structure
The message header,
which contains metadata
about the message
The message payload, which
contains your business-specific
data.

12. Inbound Properties
Inbound properties are immutable, are automatically generated by the message source
and cannot be set or manipulated by the user.
They contain metadata specific to the message source that prevents scrambling of data
formats or other processing mishaps later in the message’s lifecycle.
A message retains its inbound properties only for the duration of the flow.

13. Outbound Properties
 Outbound properties are mutable;
 they are set during the course of a flow and can become inbound properties when
the message passes from the outbound endpoint of one flow to the inbound
endpoint of a different flow via a transport.
 They contain metadata similar to that of an inbound property, but an outbound
property is applied after the message enters the flow.
 can be set automatically by Mule or a user can set them by manually inserting one
or more transformer elements in the flow.

14. Variables
 Variables are user-defined metadata about a message. Variables have three
scopes:
 Flow variables apply only to the flow in which they exist.
 Session variables apply across all flows within the same application.
 Record variables apply only to records processed as part of a batch.
 Variables are temporary pieces of information about a message that are meant to
be used by the application that is processing it, rather than passed along with the
message to its destination.

15. Elements in a Mule Flow
Connectors
• Endpoint-Based Connectors – VM, File,
JMS
• Operation-Based Connectors- HTTP,
Database, Twitter, Salesforce
• Global Connector Configuration
Components
• Scripting Components – groovy, javascript,
ruby
• Web Service Components- REST, SOAP
• HTTP Component- HTTP Static Resource
Handler
Transformers
 prepares a message for further
processing by enhancing or
altering the contents
 Object to JSON/ XML, Dataweave
Filters
• Implements basic operators AND,
OR, NOT
Routers
• Based on conditions routes to
different flows
Scopes
• Transactional element
Exceptions Strategies

16. Important Links
 Mule ESB Introduction:
 https://www.mulesoft.com/resources/esb/what-mule-esb
 Mule Message Structure:
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-message-structure
 Mule Elements:
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-connectors
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-components
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-transformers
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-filters-scopes-and-routers
 https://docs.mulesoft.com/mule-user-guide/v/3.7/mule-exception-strategies