The document discusses the architecture and components of Mule, an open-source integration platform. It describes three main layers: the application layer containing business logic, an integration layer for mediation, and a transport layer. Key components are service components containing business logic, flows/services for orchestration, and transports for integration. The Mule configuration file is used to define connectors, endpoints, and flows/services that compose message processing pipelines.

1. Presented by
Sindhu VL

2. There are three layers in the architecture :
 The application layer,
 The integration layer,
 The transport layer.

4.  Service Component Development: Developing or reuse
existing POJOs, services, Cloud Connectors, or Spring beans
that contain the business logic and will consume, process, or
enrich messages.
 Service Orchestration: Configuring message processors,
routers, transformers, and filters that provide the service
mediation and orchestration capabilities required to allow
composition of loosely coupled services using a Mule Flow.
 Integration: A key requirement of service mediation is
decoupling services from the underlying protocols. Mule
provides transports to allow dispatching and receiving
messages on different protocol connectors. These connectors
are configured in the Mule configuration and then can be
referenced from the orchestration layer.

5.  A service component is a class, web service, or
other application that contains the business logic
you want to plug in to the Mule service bus. You
can use any existing :
 Java class,
 Spring bean,
 Groovy script,
 Cloud Connector, or create a new component.
 Your service component does not need to contain
any Mule-specific code. All the Mule-specific
instructions will be configured on the service that
wraps the service component.

6.  The Mule configuration file allows you to configure
all the elements you need in your Mule instance.
 <configuration> element is used to set global
configuration options such as the threading profile.
 Then define the connectors, transformers, and
endpoints to be used in different flows. Lastly,
configure flows or service models, which act as
containers for services and orchestration elements
and apply settings such as the queue profile and
error handling to all the services in that flow or
service model.

7.  Configure a flow using the <flow> element in
the Mule configuration file.
 The flow creates a composition around the
service component(s) that will allow to define
how messages are routed, filtered,
transformed and enriched before or after
processing by one or a series of service
components.
 Flows are more flexible and robust than the
traditional service model in Mule, allowing a
more natural and compact means of
describing service orchestration.

8. Service can be configured within
a <model> element in the Mule
configuration file.
The service points to the service
component, routers, filters, and
transformers.
It also specifies the endpoint on which this
service will receive messages and the
outbound endpoint where messages will
go next.

9.  Message Processors are the basic building
blocks in Mule and in fact, components,
routers, filters, and transformers are all
message processors.
 There are also other special message
processors that do not fall in one of those
categories.
 These include a number of specialized
modules like CXF and Jersey Web Services,
BPM, as well as a few specialized integration
elements like <poll>, <content-enricher>,
and <logger>.
 Custom message processor can also be
created easily.

10.  Router types :
 Inbound routers
 Outbound routers
 Default routers (many)
 Inbound routers specify how messages are routed
to a service.
 Outbound routers specify how messages are
routed after the service has finished processing
them.
 There are several default routers that come with
Mule that you can use, or you can create your own
routers.

11. Filters specify conditions that must be met
for a message to be routed to a service.
There are several default filters that come
with Mule that you can use, or you can
create your own filters.

12. Transformers convert incoming payload
data to the type required by the service
component.
After the service has finished processing
the message, they can also convert the
message to a different type as needed by
the outbound transport.
There are several default transformers you
can use, or create your own.

13.  Mule provides default transports for many different
channels, including :
 File,
 FTP,
 HTTP,
 JMS,
 JDBC,
 Quartz, and many more.
 Transports communicate with the channel using a
connector.
 There are also many community-contributed
transports and Cloud Connectors on Mule Forge.

14. Cloud Connectors are actually message
processors that are used to speak to
application APIs over existing transports -
almost always HTTP.
Cloud Connectors typically connect
 SaaS applications,
 Social media,
 Cloud infrastructure services,
 Cloud-based data services.

15. Mule provides a complete set of APIs for
extending Mule. Typical custom extensions
include:
 Cloud Connectors
 Transports
 Custom Message Processors
 Custom Transformers
 Configuration Patterns

16. Still more to learn!!!!!!!!!!!! STAY
TUNED!!!!!!