Mule ESB is an open source enterprise service bus (ESB) that allows for lightweight and flexible integration. It uses a loosely coupled architecture and supports major protocols and technologies. Mule ESB uses a staged event-driven (SEDA) architecture that decomposes services into stages for modularity and code reuse. It processes messages using universal message objects (UMOs) and endpoints, with transports handling specific protocols and connectors sending/receiving messages. Transformation and routing are done through transformers, routers, and an exception strategy handles errors.

1. MULE ESB BASIC
INTRODUCTION

2. ENTERPRISE SERVICE BUS
ENTERPRISE SERVICE BUS
• SOFTWARE ARCHITECTURE CONSTRUCT
• CROSS PLATFORM BUSINESS INTEGRATION
• PROVIDE SERVICES THROUGH EVENT DRIVEN & MESSAGING
BUS
• LOOSELY COUPLED ARCHITECTURE

3. ENTERPRISE SERVICE BUS
Enterprise Without ESB – Point to Point Integration with ESB

4. ENTERPRISE SERVICE BUS
Processes
People
Partners Applications Legacy Applications

5. ENTERPRISE SERVICE BUS
Declarative Transformation includes:
Message Normalization,
Validation, Enrichment,
Via XSLT, Groovy, Java, StringTemplate
Service
Registry
UDDI
ESB
Message
Store
Transformation Routing
Infrastructure Services
Security Management
Declarative
Orchestration
Engine
BPEL
jPDL
Process
Store
Event
Notification
Pluggable Architecture
for integrating infrastructure services
Web Services
EJB
POJOs
Business Service
Components
Business
Data
RDBMS
Legacy
COTS
Business Services
runs within a container or
standalone
Service Data Object
Service Component Architecture
HTTP(S)
FTP
File
JMS
Email
SOAP
Excel
Browser
Java
Native
ASCII
XML
Binary
Transports
Web
SQL
Event Listeners and Actions
provide transport mediation
Socket
Hibernate
JCA/Inflow
Custom
Action
Seam
Drools
Spring
Groovy

6. MULE ESB
Mule
 Open Source ESB
 One of the Most Preferred ESB
 Lightweight & Flexible
 Loosely Coupled Architecture
 Supports Major Protocols, Technologies, Platforms

7. MULE ESB – LOOSE COUPLING
Loose Coupling
The consumer of the service is required to provide only the
stated data on the interface definition, and to expect only
the specified results on the interface definition.
The service is capable of handling all processing (including
exception processing).

8. MULE ESB – SEDA ARCHITECTURE
SEDA – Staged Event Driven
 Decomposing a complex, event-driven software application into a set of
stages connected by Queues
 Avoiding the high overhead associated with thread-based concurrency
models
 Decouples event and thread scheduling from application logic
 Admission control on each event queue – Load Balancing
 Decomposing services into a set of stages for modularity and code reuse

9. MULE ESB – CONCEPTS
UMO – Universal Message Objects
•A UMO is a type of Java object that can
•receive events "from anywhere"
•send events
•UMO Components are usually your business objects. They are components
that execute business logic on an incoming event
•UMO are standard JavaBeans (containers)
•There is no Mule-specific code in your components
•Mule handles all routing and transformation of events to and from your objects
based on the configuration of your component

10. MULE ESB – CONCEPTS
End Points
 InBound EndPoints
 Kicks an Event
 Called by External Clients
 OutBound EndPoints
 Called by Mule Flow
 Publish Data to Service, Application & Resource

11. MULE ESB – CONCEPTS<mule-configuration>
<model>
<mule-descriptor>
<inbound-router>
<endpoint
address="file:///c:/mule-class/in"/>
</inbound-router>
<outbound-router>
<router>
<endpoint
address="file:///c:/mule-class/out"/>
</router>
</outbound-router>
</mule-descriptor>
</model>
</mule-configuration>
<inbound-router>
<endpoint address="file:///c:/mule-class/in">
<filter pattern="*.xml"
className=
"org.mule.providers.file.filters.FilenameWildcardFilter"/>
</endpoint>
</inbound-router>

12. MULE ESB – CONCEPTS
Transports
A transport or "provider", is a set of objects that add support to Mule to handle a specific kind of
transport or protocol
Examples
SMTP/FTP/Queues
the "Email Provider" enables Mule to send and receive messages via the SMTP, POP and IMAP
protocols

13. MULE ESB – CONCEPTS
Connectors
•A connector is the object that sends and receives messages on behalf of an endpoint.
•Connectors are bundled as part of specific transports or providers.
•For example, the FileConnector can read and write file system files
Router
•A router is the object that do something with messages once they have been received by
a connector, or prior to being sent out by the connector

14. MULE ESB – CONCEPTS
Transformer
A transformer optionally changes incoming or outgoing messages in some way
This is usually done to make the message format useable by a downstream function
Examples:
the ByteArrayToString transformer converts byte arrays into String objects.

15. MULE ESB – EVENT FLOW
 The nine stages of a mule
event
 first 2 – inbound
 middle 4 – component
 last 2 – outbound
Endpoint
(Message Receiver)
Endpoint
(Message Dispatcher)
Inbound Router
Outbound Router
Inbound Transformer
Outbound Transformer
Interceptor
Service Invocation
Interceptor
Inbound
Component
Outbound
Optional Step

16. MULE ESB – SERVICE INVOCATION
 The actual service is performed
 In mule, this is generally a Java
object
 Service invocation can also be a
"pass through"
Endpoint
(Message Receiver)
Endpoint
(Message Dispatcher)
Inbound Router
Outbound Router
Outbound Transformer
Interceptor
Interceptor
Inbound Transformer
Service Invocation

17. MULE ESB – EXCEPTION
HANDLING
Exception Handling
• Mule has a special way of handling error processing.
• This is called an "Exception Strategy" but is it really just and exception
path and there is very little strategy involved.
• There are three places you can associate an exception strategy
• connector
• component
• model (set for all components in a model)

18. MULE ESB – EXCEPTION STRATEGY<exception-strategy
className=org.mule.impl.DefaultComponentExceptionStrategy">
<endpoint address="file:///c:/mule-class/error"/>
</exception-strategy>

19. MULE ESB – CONCEPTS – MULE
STUDIO