This document provides an overview of the core concepts in Mule ESB, including models, services, transports, connectors, endpoints, transformers, routers, filters, and components. The model layer defines Mule's runtime environment and behavior. Services are composed of Mule entities that process requests. Transports handle message receiving and sending via connectors like File, JDBC, HTTP, and JMS. Endpoints define entry and exit points for messages. Transformers optionally change message formats. Routers control message flow. Filters restrict messages. And components contain business logic.

1. Mule ESB – Core concepts
By
Mur@li

2. Model :
 The first logical layer is the model layer. A Mule model
represents the run-time environment that hosts services.
 It defines the behavior of Mule when processing requests
handled by these services.
 Consequently, the model that the Mule instance would host
would establish a runtime environment optimized for
asynchronous processing of messages, as no synchronous
reply is expected anywhere in the overall message processing
chain.

3. Service :
 A Mule service is composed of all the Mule entities involved in
processing particular requests in predefined manners.
 A service is defined by a specific configuration. This
configuration determines the different elements, from the
different layers of responsibility, that will be mobilized to process
the requests that it'll be open to receive.
 Depending on the type of input channel it uses, a service may
or may not be publicly accessible outside of the ESB.
 For the time it gets handled by a service, a request is
associated with a session object.
 As its name suggests, this object carries all the necessary
context for the processing of a message while it transits through
the service.

4. Transports :
 The transport layer is in charge of receiving or sending
messages. This is why it's involved with both inbound and
outbound communications.
 A transport manifests itself in the configuration by the
following elements: connectors, endpoints and transformers.

5. Connectors :
 A connector is in charge of controlling the usage of a
particular protocol.
 It's configured with parameters that are specific to this
protocol and holds any state that can be shared with the
underlying entities in charge of the actual communications.
 For example, the File Connector can read and write file
system files.

6. Configuring connectors :
1. File Connector
2. JDBC Connector
3. HTTP Connector
4. JMS Connector

7. 1. File Connector :
The configuration for file connector is as follows:
<file:connector name="FileConnector" streaming="false"
pollingFrequency="1000">
<file:expression-filename-parser/>
</file:connector>

8. 2. JDBC Connector :
The configuration for JDBC connector is as follows :
<jdbc:connector name="jdbcConnector" dataSource-
ref="dataSource“>
<jdbc:query key="statsInsert" value="insert into alerts values (0, 123,
Murali', employee')"/>
</jdbc:connector>

9. 3. HTTP Connector :
The configuration for HTTP connector is as follows :
<http:connector name="HttpConnector"
proxyHostname="${proxyHostname}"
proxyPort=="${proxyPort}"
proxyUsername="${proxyUsername}"
proxyPassword="${proxyPassword}"/>

10. 4. JMS Connector :
The configuration for JMS connector is as follows :
<jms:activemq-connector
name="jmsQueueConnector"
specification="1.0.2b"
brokerURL="tcp://localhost:61616"/>

11. Endpoints :
 Inbound and outbound endpoints exist in the context of a
particular service and represent the expected entry and exit
points for messages, respectively.
 These end-points are defined in the inbound and outbound
routers.
 It's also possible to define an inbound endpoint in a response
router.
 In that case, the inbound endpoint acts as a response endpoint
where asynchronous replies will be consolidated before the
service returns its own response.
 Global endpoints can be considered abstract entities that get
reified only when referenced in the context of a service: as such,
they're a convenient way to share common configuration
attributes.

12. Transformers:
 A transformer optionally changes incoming or outgoing messages in some
way. This is usually done to make the message format useable by a down
stream function
For examples, the ByteArrayToString transformer converts byte arrays into
String objects. If we want our own transformers to convert input we can write
our own java and we can call from the mule.
 We can implement custom java transformer by extends AbstractTransformer
and AbstractMessageAwareTransformer.
AbstractTransformer is a normal Transformer, it will carry only payload in
the sense input/result from before execution.
AbstractMessageAwareTransformer is a special transformer, It will carry
payload, messahe properties of mule and alo details regarding exception.

13. Routers :
 Routers play a crucial role in controlling the trajectory a message will follow
when it transits in Mule.
 They're the gatekeepers of the endpoints of a service. In fact, they act like
railroad switches, taking care of keeping messages on the right succession
of tracks so they can reach their intended destinations.
 A router is the object that does something with messages once they have
been received by a connector, or prior to being sent out by the connector.
 pass-through-router: Input will pass as it is to outbound from inbound.
Single service will be available.
 filtering-router: input will pass based on condition it's like filtering input.
Multiple Services will be available.
 chaining-router: Every statement will pick up by procedure functionality,
nothing but there is no condition after finishing one service it will go to the
next service. Multiple Services will be available. etc...

14. Filters :
 A filter optionally filters incoming or outgoing messages that are
coming into or going out from a connector.
 For example, the File Provider comes with a Filename
WildcardFilter that restricts which files are read by the connector
based on file name patterns.
 For example only files with the .xml extension can be routed.
 Note: writing condition is filtering-router and way of condition is
filter. Based on filter, service will be picking up by filtering-router.

15. Components :
 Components are usually business objects.
 They are components that execute business logic on an
incoming event.
 Components are standard JavaBeans (containers).
 There is no Mule-specific code in components, it is a java class
to implement business logic especially.

16. Thank Q