The document discusses core concepts in Mule including: - The model layer represents the runtime environment that hosts services and defines Mule's behavior when processing requests. - Services are composed of Mule entities that process requests in predefined ways based on a service's configuration. - Transports handle message receiving and sending using connectors, endpoints, and optional transformers. - Connectors control usage of protocols, endpoints define entry/exit points, and transformers optionally change message formats. - Routers control message flow by routing to appropriate endpoints, filters optionally filter messages, and components execute business logic.

1. Core concepts in Mule
Presented by
Sindhu VL

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

6. Configuring connectors :
 FileConnector
 JDBC Connector
 HTTP Connector
 STDIO Connector
 JMS Connector
 Proceed to next slide to see the
configuration of all the above connectors.

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

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

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

10. STDIO Connector :
The configuration for STDIO connector is as
follows :
<stdio:connector
name="SystemStreamConnector"
promptMessage="Please enter
something:" messageDelayTime="1000"
/>

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

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

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

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

15. Filter :
 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
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.

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

17. Thank You