Presented by

Sindhu VL

Core concepts in Mule

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.

Model :

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 pro-cessing of a message while it transits
through the service.

Service :

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.

Transports :

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 FileConnector can read
and write file system files.

Connectors :

FileConnector
JDBC

Connector
HTTP Connector
STDIO Connector
JMS Connector

Proceed to next slide to see the

configuration of all the above connectors.

Configuring connectors :

The configuration for file connector is as

follows:
<file:connector name="FileConnector"
streaming="false" pollingFrequency="1000">
<file:expression-filename-parser/>
</file:connector>

FileConnector :

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, 344,
Sindhu', Vankam')"/>
</jdbc:connector>

JDBC Connector :

The configuration for HTTP connector is as

follows :
<http:connector name="HttpConnector"
proxyHostname="${proxyHostname}"
proxyPort=="${proxyPort}"
proxyUsername="${proxyUsername}"
proxyPassword="${proxyPassword}"/>

HTTP Connector :

The configuration for STDIO connector is as

follows :
<stdio:connector
name="SystemStreamConnector"
promptMessage="Please enter
something:"
messageDelayTime="1000" />

STDIO Connector :

The configuration for JMS connector is as

follows :
<jms:activemq-connector
name="jmsQueueConnector"
specification="1.0.2b"
brokerURL="tcp://localhost:61616" />

JMS Connector :

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.

Endpoints :

transformer optionally changes incoming or outgoing messages

in some way.This is usually done to make the message format
useable by a downstream 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.

Transformer :

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...

Routers :

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
FilenameWildcardFilter 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.

Filter :

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.

Components :

Thank You