Welcome to Mule ESB Tutorials. The objective of these tutorials is to provide in depth understand of Mule ESB.
In addition to free Mule ESB Tutorials, we will cover common interview questions, issues and how to’s of Mule ESB.
Mule, the runtime engine of Anypoint Platform, 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. 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.
The key advantage of an ESB is that it 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. 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
Overview of a Mule Configuration
Many Mule elements can be specified at the global level, that is, as direct children of the outermost
mule element. These global elements always have names, which allows them to be referenced where they’re used. Note that a Mule configuration uses a single, flat namespace for global elements. No two global elements can share the same name, even if they are entirely different sorts of things, say an endpoint and a filter.
Let’s examine the most common global elements:
A connector is a concrete instance of a Mule transport, whose properties describe how that transport is used. All Mule endpoints use transports which inherit the connector’s properties.
A Mule ESB configuration file is a tree,
Each of these elements provides access to configuration objects within Mule:
-Flows - Use message processors to define message flow between a source and a target.-Mule Global Configuration - Global settings, such as the default transaction time-out, that apply to the entire Mule configuration-Connectors - Non-default configuration of any transports used-Endpoints - Define the channel and address or path where messages are sent or received. You can define them globally and use them in multiple flows.-Transformers - Convert data from one format to another. You can define them globally and use them in multiple flows.-Filters - Filter out the messages that don’t match specific criteria. You can define them globally and use them in multiple flows.
Following is an example of a simple Mule configuration file:
<vm:connector name="vmConnector" queueTimeout="5000"/>
<vm:endpoint name="CustomerRequests" path="customer.requests"/>
<vm:endpoint name="CustomerResponses" path="customer.responses"/>
<custom-transformer name="ThisToThat" class="com.acme.transformer.ThisToThat"/>
<outbound-endpoint ref="CustomerResponses" transformer-refs="ThisToThat"/>
-Security Manager - Authenticates requests based on one or more security providers
-Agents - Agents are typically used for cross-cutting concerns such as logging or management
-Notifications - Allow you to be notified upon certain lifecycle events
-Transaction Management - Mule transactions are configured on inbound endpoints, where an endpoint can be configured to start a new transaction or join an existing one.
-Properties - Property placeholders, message properties, and system properties.
-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.
-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 airline processes over 10,000 business transactions per second with Mule while H&R Block uses 13,000 Mule servers to support their highly distributed environment.