5. Enterprise Service Bus
An enterprise service bus (ESB) implements a communication system between
mutually interacting software applications in a service-oriented architecture (SOA).
All customer services communicate in the same way with the ESB: the ESB
translates a message to the correct message type and sends the message to the
correct consumer service.
Hide Complexity
Simplify access
Canonical pattern Support
Integration driven by business requirements not by available technology
6. Features of ESB
Route messages between services
Monitor and control routing of message exchange between services
Resolve contention between communicating service components
Control deployment and versioning of services
Marshal use of redundant services
Provide commodity services like event handling, data transformation and mapping,
message and event queuing and sequencing, security or exception handling,
protocol conversion and enforcing proper quality of communication service
7. Mule ESB
Mule, the runtime engine of Anypoint Platform, is
lightweight Java-based enterprise service bus (ESB) and integration platform
Allows developers to connect applications together quickly and easily, enabling them to
exchange data.
It enables easy integration of existing systems, regardless of the different technologies
that the applications use, including JMS, Web Services, JDBC, HTTP, and more.
The ESB can be deployed anywhere, can integrate and orchestrate events in real time or
in batch, and has universal connectivity.
8. Why Mule?
Mule has powerful capabilities that include:
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
9.
10. Advantages over competitors
Mule components can be any type you want. 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. (No Programming or
mule specific code changes are required)
Messages can be in any format from SOAP to binary image files. Mule does not force
any design constraints on the architect, such as XML messaging or WSDL service
contracts.
You can deploy Mule in a variety of topologies, not just ESB. Because it is lightweight
and embeddable, Mule can dramatically decrease time to market and increases
productivity for projects to provide secure, scalable applications that are adaptive to
change and can scale up or down as needed.
Mule's stage event-driven architecture (SEDA) makes it highly scalable. A major financial
services company processes billions of transactions per day with Mule across thousands
of Mule servers in a highly distributed environment.
11. Mule Message Structure
The message header,
which contains metadata
about the message
The message payload, which
contains your business-specific
data.
12. Inbound Properties
Inbound properties are immutable, are automatically generated by the message source
and cannot be set or manipulated by the user.
They contain metadata specific to the message source that prevents scrambling of data
formats or other processing mishaps later in the message’s lifecycle.
A message retains its inbound properties only for the duration of the flow.
13. Outbound Properties
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.
They contain metadata similar to that of an inbound property, but an outbound
property is applied after the message enters the flow.
can be set automatically by Mule or a user can set them by manually inserting one
or more transformer elements in the flow.
14. Variables
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 only to records processed as part of a batch.
Variables are temporary pieces of information about a message that are meant to
be used by the application that is processing it, rather than passed along with the
message to its destination.
15. Elements in a Mule Flow
Connectors
• Endpoint-Based Connectors – VM, File,
JMS
• Operation-Based Connectors- HTTP,
Database, Twitter, Salesforce
• Global Connector Configuration
Components
• Scripting Components – groovy, javascript,
ruby
• Web Service Components- REST, SOAP
• HTTP Component- HTTP Static Resource
Handler
Transformers
prepares a message for further
processing by enhancing or
altering the contents
Object to JSON/ XML, Dataweave
Filters
• Implements basic operators AND,
OR, NOT
Routers
• Based on conditions routes to
different flows
Scopes
• Transactional element
Exceptions Strategies
https://docs.mulesoft.com/mule-user-guide/v/3.7/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. However, as attachments and exception payloads are not frequently used or manipulated
Anypoint Connectors receive or send messages between Mule and one or more external sources, such as files, databases, or Web services. Connectors can act as message sources by working as inbound endpoints, they can act as a message processor that performs an operation in middle of a flow, or they can fall at the end of a flow and act as the recipient of the final payload data.
Connectors in Mule are either endpoint-based or operation-based. Endpoint-based connectors follow either a one-way or request-response exchange pattern and are often (but not always) named and based around a standard data communication protocol, such as FTP, JMS, and SMTP. 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
Components are message processors which execute business logic on messages. They enable you to perform specific actions without writing any Mule-specific code. You can drop a component – a POJO, Spring bean, Java bean, or script – into a flow to perform almost any customized task within your Mule application. For example, you can use a component to verify that items on an invoice are in stock in a warehouse, or to update a database with a customer’s order history
In a Mule flow, a Transformer prepares a message for further processing by enhancing or altering the contents of the message properties, variables, or payload. Data transformation is one of the most powerful functionalities of Mule: rather than spending a lot of time building a customized connection between resources or processors, you can just use a pre-built transformer to perform a standard data conversion. For example, if the message source in a flow receives data in XML format, but a downstream message processor expects a Java object, you can use an XML-to-Object transformer to convert the format of the message payload
Mule scopes work to encapsulate other message processors so that they function as a single unit. You might wrap several message processors together to form a transactional unit, so that they succeed or fail to process a message together, thus ensuring accurate updating of a database, for example. You might wrap several message processors together within a cache scope to store the result of their processing for reuse, or wrap a single message processor within a message enricher scope to add to a message payload without manipulating the original contents.
Mule routers – or flow controls, as they’re known in Anypoint Studio – function much as their name implies: to direct or otherwise control messages within a flow.
At times, flow controls act as splitters, resequencers, or aggregators, splitting messages into individual items for processing, resequencing message content, or aggregating split messages.
At times, they act as forks in the road, evaluating a message’s payload, properties, or variables, then routing to the message down a particular "pathway" according to those contents. Thus, flow controls facilitate content-based routing. For example, you can use a choice flow control to examine part of a message payload, then route the message to the first "pathway" for which the set condition evaluates to true, such as where an order exceeds $5,000
Mule provides numerous options for handling errors. Errors, or faults, that occur within Mule are referred to as exceptions; when an activity in your Mule instance fails, Mule throws an exception. To manage these exceptions, Mule allows you to configure exception strategies.
Mule’s default exception strategy — which implicitly applies to all Mule applications — manages errors (such as, thrown exceptions) in Mule flows. When your flows require more sophisticated error management, you can implement one or more exception strategies to construct precise, efficient protocols for handling errors.
From a high level perspective, errors that occur in Mule fall into one of two categories: System Exceptions, and Messaging Exceptions
