about mule technology

1. Mule ESB

2. What is Mule ESB?
• Mule is a lightweight Java-based enterprise service bus (ESB) and integration
platform that allows developers to connect applications together quickly and
easily, enabling them to exchange data and allows different applications to
communicate with each other by acting as a transit system for carrying data
between applications within your enterprise or across the Internet.
• It enables easy integration of existing systems, regardless of the different
technologies that the applications use.
Example: JMS, Web Services, JDBC, HTTP, and more

3. Capabilities of Mule
• Service creation and hosting — expose and host reusable services, using the ESB
as a lightweight service container
• Service mediation — shield services from message formats and protocols,
separate business logic from messaging, and enable location-independent service
calls
• Message routing — route, filter, aggregate, and re-sequence messages based on
content and rules
• Data transformation — exchange data across varying formats and transport
protocols

4. Do I need an ESB and when to select an ESB?
It is form the article written by MuleSoft founder and VP of Product Strategy Ross Mason: To ESB or not to ESB.
1. Are you integrating 3 or more applications/services?
2. Will you need to plug in more applications in the future?
3. Do you need to use more than one type of communication protocol?
4. Do you need message routing capabilities such as forking and aggregating
message flows, or content-based routing?
5. Do you need to publish services for consumption by other applications?

5. Advantages of Mule provides over other
competitors
• Mule's stage event-driven architecture (SEDA) makes it highly scalable.
• Mule components can be any type you want. You can easily integrate anything from
a "plain old Java object" (POJO) to a component from another framework.
• Mule and the ESB model enable significant component reuse.
• Unlike other frameworks, Mule allows you to use your existing components without
any changes. Components do not require any Mule-specific code to run in Mule,
and there is no programmatic API required. The business logic is kept completely
separate from the messaging logic.

6. Mule Enterprise
• There are two editions of Mule. Community and Enterprise.
• Enterprise is the enterprise-class version of the ESB, with additional features
and capabilities that are ideal for production deployments of Mule that have
requirements for performance, HA, resiliency, or technical support.
https://www.mulesoft.com/platform/soa/mule-esb-enterprise

7. Installation

8. Anypoint Studio
• Canvas /Message Flow
• Global Elements
• Configuration XML
• Palette ( where mule building blocks/elements are available )
1. Connector 4. Transformers
2. Scope 5. Filters
3. Components 6. Flow Control elements (or "Routers")

9. Message Sources
• Mule processes messages, also known as events.
• which may be transmitted from resources external to Mule.
Example: A message can be initiated by an event
• Such as a consumer request from a mobile device.
• A change to data in a database.
• The creation of a new customer ID in a Software as a service(Saas) application.
• The first building block of most flows is a receiver which receives new messages and places them in the queue for processing. This
message source – receives messages from one or more external sources, thus triggering the execution of a flow.
• Message sources in Mule are usually Anypoint Connectors, elements which provide connectivity to a specific external source, either via
a standard protocol (such as HTTP, FTP, SMTP) or a third-party API (such as Salesforce.com, Twitter, or MongoDB.)

10. Message Processors
• In Mule, message processors are grouped together by category.
• Mule transformers are the key to exchanging data between nodes.
• Mule to convert message payload data to a format that another application can
understand.
• Mule uses Staged Event-Driven Architecture (SEDA) for core asynchronous
message processing in flows.
• Importantly, components don’t have to have any Mule-specific code.
• It can be simply be POJOs, Spring beans, Java beans, Groovy scripts, Python, JavaScript,
Ruby, and PHP or web services containing the business logic for processing data.

11. Mule Flow
• A flow is the most versatile and powerful
integration mechanism available in Mule.
• A flow is the construct within which you link
together several individual elements to handle the
receipt, processing, and eventual routing of a
message.
• You can connect many flows together to build a
complete application and each names should be
unique.
Private Flows, Sub Flows, Flow-Ref

12. Mule Message Structure
The Mule message is the data that passes through an application
via one or more flows. It consists of two main parts:
• The message header, which contains metadata about the
message.
• The message payload, which contains your business-specific
data.
• A Mule message is, itself, embedded within a Mule message
object.
• Some Mule message objects may contain variables,
attachments, and exception payloads

13. Mule Expression Language
Mule Expression Language (MEL) is the primary language used for formulating
expressions in Mule, allows us to access, manipulate, and use information from
the message and its environment.
• MEL is a lightweight and Mule-specific expression language that you can use to access and
evaluate the data in the payload, properties and variables of a Mule message.
• Accessible and usable from within virtually every message processor in Mule.
• MEL enables you to quickly and elegantly filter, route, or otherwise act upon the different
parts of the Mule message object.
#[message.inboundProperties.propertyName]

14. Properties & Variables
• The metadata contained in the message header consists of properties which
provide useful information about the message.
• Properties and Variables share a common format: each individual property or
variable has a name and a value.
• A message’s properties and variables have specific scopes that define and
organize how they apply across that message’s lifecycle.

15. • Properties have two main scopes: inbound and outbound.
• Inbound properties are immutable, are automatically generated by the message source and
cannot be set or manipulated by the user.
• Outbound properties are mutable; they are set during the course of a flow and can become
inbound properties when the message passes from the outbound endpoint of one flow to the
inbound endpoint of a different flow via a transport.

16. • Variables are user-defined metadata about a message. Variables have three scopes:
• Flow variables apply only to the flow in which they exist.
• Session variables apply across all flows within the same application.
• Record variables apply to only to records processed as part of a batch.

17. Anypoint Studio
• Palette (Message Processors)
1. Connector
2. Scope
3. Components
4. Transformers
5. Filters
6. Flow Control elements (or "Routers")
7. Error Handling
8. Security

18. Anypoint Connectors
• Anypoint Connectors receive or send messages between Mule and one or
more external sources.
• Connectors can act as message sources by working as inbound endpoints.
• Connectors can act as a message processor that performs an operation in the
middle of a flow.
• Connectors can be at the end of a flow and act as the recipient of the final
payload data.

19. Connectors in Mule are either endpoint-based or operation-based
Endpoint-Based Connectors
• Endpoint-based connectors follow either a one-way or request-response exchange pattern.
• Endpoint-based connectors are configured as either inbound or outbound endpoints in a flow.
• Inbound endpoints serve as a message source for a flow.
• Outbound endpoints can occur mid-flow or at the end of flows and send information to external
systems.
• Connectors often (but not always) named and based around a standard data communication
protocol
such as FTP and SMTP.
Operation-Based Connectors
• Operation-based connectors follow an information exchange pattern based on the operation that
you select and are often (but not always) named and based around one or more specific third-party
APIs.
• When you add an operation-based connector to your flow, you immediately define a specific
operation for that connector to perform.
Global Connector Configurations

20. Components
• Components are the message processors which is embedded with business
logic and it is executes on message.
• Components fall into three categories
1. General Components
2. Script Components
3. Web service Components.

21. • General Components
• General components execute whenever a message is received.
• The logic embedded into General components cannot be modified.
• Components such as the Logger and Flow Reference fall into this category.
• Script Components
Script components do not contain pre-packaged logic. Instead it allows the developer to specify the logic
(in the form of a custom script or a Java class) to add into the component.
• Script components also allow you to:
• Configure interceptors
• Add Spring beans
• Change the value or reference of a specific property within the associated class
• The Java Component allows you to reference a Java class.
• The other Script components support the Groovy, JavaScript, Python and Ruby scripting engines.

22. • Web Service Components
Web Service components provide or facilitate the developer in exposing, consuming, and
proxying web services with the framework to reference classes and API’s needed by RESTful and
SOAP Web services. These components let you add interceptors, bundled logic which executes
before the service is published, that run tasks such as scheduling or logging a specific event.
• The CXF component leverages the CXF framework, mule uses to support SOAP web services.
• The REST component work with Jersey to support REST Web services.

23. Batch
Batch is a new Mule construct that provides the ability to process messages in
batches. Within an application, you can initiate a batch job which is a block of
code that splits messages into individual records, performs actions upon each
record, then reports on the results and potentially pushes the processed output
to other systems or queues. This functionality is particularly useful when
working with streaming input or when engineering “near real-time” data
integration between SaaS applications.

24. Batch

25. Phases

27. Record Variable