This document provides an overview of Mule ESB, including its key elements and features. Mule ESB is a lightweight, Java-based integration platform that allows developers to connect applications quickly using its built-in connectors. It can integrate and orchestrate events in real-time or in batch mode using a staged event-driven architecture. Mule applications are composed of flows that contain message processors and can communicate with other flows and external resources.

1. MULE ESB OVERVIEW
Gunjan Deshmukh

2. TOPICS
• Overview
• Mule Elements
• The Mule Message
• Anypoint Studio
• Data formats
• Anatomy of Mule Flow
• Exchange Patterns
• Flow Processing Strategy
• Anypoint Platform

3. OVERVIEW
• Mule ESB is a light weight Java based ESB and integration platform that allows
developers to connect applications together quickly and easily.
• It has many in built connectors which aid in easy integration of existing systems,
regardless of different technologies.
• It can be deployed anywhere, can integrate and orchestrate events in real time or in
batch mode. It is SEDA based.
• SEDA is an Staged event-driven architecture and decomposes applications into set
of stages connected by queues.
• There are two editions of Mule, community and enterprise.

4. MULE ESB FEATURES
• 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.
• SOA Governance – Apply security policies on the API in a configurable manner independent of the code.
• Analytics – Provides real time analysis and monitoring capability.
• Cloud Ready – Services can be deployed on cloud server which can be scaled both horizontally and
vertically.

5. MULE ELEMENTS
• Flow
• Mule Applications are composed of flows. Flows are initiated by a Message Source.
Flows contain message processors. Flows can send messages off to other flows and
eventually external resources.
Message
Source
Message
Processor
Message
Processor
Message
Source
Message
Processor
Message
Processor
Flow 1
Flow 2

6. MESSAGE PROCESSORS
• Components: perform business logic & are typically application specific. e.g. Java,
Groovy, Python, etc.
• Transformers: transform the message from one format to other. e.g. DOM to XML, Byte
Array to String, JSON to XML, etc.
• Filters: accept/reject messages based on a condition. e.g. And, Expression, Not, Regex,
etc.
• Routers: control the message flow. e.g. Choice, Scatter-Gather, Splitter, etc.
• Endpoints: send/receive messages over a transport. e.g. HTTP, File, DB, JMS, SFDC, etc.
• Scopes: adds functionality on embedded message processors e.g. Async, Cache,
Transactional, etc.

7. COMPONENTS

8. TRANSFORMERS

9. FILTERS

10. ROUTERS

11. CONNECTORS

12. SCOPES

13. THE MULE MESSAGE
Inbound
Properties
Outbound
Properties
Payload
AttachmentVariable
ExceptionPayload
Header
Message
Message Object

14. THE MULE MESSAGE
• The mule message is the data that passes through an application via one or more flows. It consists of two main parts:
• The message header, which has metadata about the message.
• The message payload, which contains business specific data.
• A mule message itself is embedded within a Mule message object. Some mule message objects may contain variables,
attachments, and exception payloads.
• Inbound properties contain metadata, message processors have read only access. They are set from the message source
and persists throughout the flow.
• Outbound properties are also metadata which can be read or modified. They are added by message processors. These
properties become inbound properties to next flow when sent via a transport.
• Payload is the core of the message. It contains primary information to be processed by Mule.
• Attachments are ancillary information to the message, similar to email attachment.
• Variables are user-defined metadata about a message. Variables have three scopes, flow, session and record level.

15. ANYPOINT STUDIO

16. ANYPOINT STUDIO
Package Explorer
• Access to all projects within workspace
• Shows libraries and runtimes used in project.
• Java files, test files, and resources used in project.
• Flow based XML files and properties files.
Canvas
• Shows Message flow in both graphical and XML format. Regardless of where we add processors in the application, they
will update each other.
• XML supports auto complete based on available namespaces. Ctrl + Space
• Global elements are defined once and referenced in the application.

17. ANYPOINT STUDIO
Palette
• Contains elements which can be added in the application
• These are categorized based on functionality.
• Helps build application by means of creating flows.
Console
• Anypoint Studio comes complete with an embedded Mule runtime to test applications
without leaving studio
• Console outputs our application logs and information

18. DATA FORMATS
• Applications work with various type of data.
• This data can contain anything from customer information to Sales numbers.
• The data often exists in many different formats.
Mule supports many data formats like XML, JSON, Streams, Binary, CSV, Objects,
Compressed, etc.

19. ANATOMY OF MULE FLOW
Message Source
Message Processor 1
Message Processor 2
Message Processor ..n
Exception Handling
Dedicated Thread pool

20. ANATOMY OF MULE FLOW
• A flow can be called by message source or a flow reference.
• Each flow operates on its own thread pool.
• Exception strategy is optional, any exception not caught in the flow goes to Mule’s
default exception strategy.

21. ANATOMY OF MULE FLOW
Subflow
• Does not have an inbound endpoint at the beginning of the flow.
• Does not have its own thread pool.
• Callable only by flow reference.
• Cannot have own error handling; errors are caught in parent flow.
Private Flow
• Same as flow but without a source at the beginning of the flow.
• Callable by a flow reference.
• Operates in its own thread pool.
• Can contain its own error handling.

22. EXCHANGE PATTERNS
• Provide a set of well-defined interaction patterns between the client and server.
• Mule supports Request Response and One-Way patterns
• Some connectors support both modes.
Request Response
• Is used when the sender of the messages expect a response or some kind of result to return to the caller.
• Mule applies synchronous processing strategy for this pattern.
• Common example is web service, API.
One-Way
• Is used when no response is expected, or when the result is sent to some other flow or system and not back to the caller.
• Mule applies asynchronous processing strategy for this pattern.
• Common example is JMS, logging.

23. FLOW PROCESSING STRATEGY
• Determine processing model used for a flow.
• It is set automatically by Mule, can be changed or fine-tuned.
• Normal strategies used are synchronous and queued asynchronous.
• It is configured based on flow exchange pattern and whether or not flow is transactional.
• Supports fine-tuning by
 Number of threads per flow
 Number of messages queued
 Persistent queues to store data

24. FLOW PROCESSING STRATEGIES
Exchange Pattern Transactional? Strategy
Request-Response Yes Synchronous
Request-Response No Synchronous
One-Way Yes Synchronous
One-Way No Queued-Asynchronous

25. FLOW PROCESSING STRATEGIES
• Other strategies available:
• Asynchronous: does not use queue, used when processing is not distributed across nodes.
• Non-blocking – uses an evented non-blocking processing model to process requests. A
thread is used to receive message and other thread can be used to respond back to caller.
• Queued-thread-per-processor: writes messages to queue, each processor in scope runs in
a different thread.
• Thread per processor: no queue, each processor runs sequentially in a different thread.

26. ANYPOINT PLATFORM
It helps design, build and manage the entire lifecycle of APIs, applications and
products. It contains many components that enable reuse, self-service, composability,
publishing, governance, and security.
• Design Center
• Anypoint Exchange
• Management Center
• Mule Runtime Engine
• Anypoint Connectors
• Runtime Services