ESB journey continues……
As mentioned in my previous blog, Enterprise service bus is a generic name for any solution that provides communication and translation between applications or between different processes within an application. ESB standardizes the notion of message bus. ESB is a topology, a way to organize components and their interactions.
In short, ESB is a way of doing things, “ a design pattern” to continue the evolution of standardizing the application integration.
The enterprise service bus is all about allowing different components or applications to communicate through a common messaging bus, usually implemented using JMS, MQ, or other messaging server. It allows traffic of all types to traverse it and has adaptors to allow servers of different message types to communicate seamlessly across the bus. For example, if you have an application that needs to raise an alarm based on some condition, and the action of that alarm is to send an email or an instant message to the administrator, the module that raises the alarm should not need to 'understand' SMTP or SIP (Session Initiation Protocol); it should just put the message on the bus and have the bus and the intended recipient handle it as they see fit
Mule is a lightweight messaging framework and an object broker that handles the interactions between your applications across JMS, e-mail, HTTP, and even XML-RPC.
Mule is in no way a replacement for existing application framework. In fact Mule leverages many open source projects such as Axis, Spring, ActiveMQ, Plexus and PicoContainer.
Mule fills a void in enterprise java development where an application requires complex interactions with a variety of systems on a variety of platforms. Mule makes light work of wiring these systems together in a robust decoupled environment and provides the necessary support to route, transport and transform data to and from these systems.
Mule provides a container that manages message-capable services known as Universal Message Objects (UMOs). UMOs can be plain old Java objects (POJOs). UMOs are made available to other UMOs and applications via message endpoints that allow messages to be routed across a wide array of protocols and technologies such as JMS, SMTP, JDBC, TCP, HTTP, file, intra-VM, etc.
Here are the principal ESB Mule components :
Mule Manager:- The Mule Manager is the primary component for each instance of a Mule server and is used to manage all Mule objects (connectors, endpoints, transformers, etc.) for each Mule server instance
Mule Model:- The Mule Model is the container in which user-supplied components are managed and executed. It controls message flow to and from user-supplied components and manages threading, lifecycle, and pooling of the components.
Universal Mule Objects (UMO) :- A UMO is a type of Java object that can
1. receive events "from anywhere"
2. send events
UMO Components are usually your business objects. They are components that execute business logic on an incoming event. UMO are standard JavaBeans (containers). Mule handles all routing and transformation of events to and from your objects based on the configuration of your component. Typically your POJO with translates into an UMO with the Mule configuration.
Connector:- A connector is the object that sends and receives messages on behalf of an endpoint. Connectors are bundled as part of specific transports or providers. For example, the FileConnector can read and write file system files. JDBC connector to connect to relational databases using jdbc. It supplies reads and writes to simple tables with acknowledgement of read rows.
Router:- A router is the object that do something with messages once they have been received by a connector, or prior to being sent out by the connector
Transports:- A transport or "provider", is a set of objects that add support to Mule to handle a specific kind of transport or protocol
Examples - the "Email Provider" enables Mule to send and receive messages via the SMTP, POP and IMAP protocols
Filter:- A filter optionally filters incoming or outgoing messages that are coming into or going out from a connector. Filters are used in conjunction with Routers
For example, the File Provider comes with a FilenameWildcardFilter that restricts which files are read by the connector based on file name patterns, like only files with the .xml extension can be routed
Transformers:- A transformer optionally changes incoming or outgoing messages in some way. This is usually done to make the message format usable by a downstream function
Examples - the ByteArrayToString transformer converts byte arrays into String objects
Endpoints:- Endpoints are used to connect to components in the server and external systems or to each other locally or over the network. An Endpoint is a specific channel through which two parties can communicate. Endpoints can be configured on various objects in Mule
- Inbound Routers - configured on Components and allow one or more endpoints to be registered on a component.
- Outbound Routers - configured on components and allow one or more outbound endpoints to be configured (with additional logic for controlling which endpoints are used for an event
- Catch all strategies - allow a single 'catch-all' endpoint to be configured for a router.
- Components - for convenience a single inbound and outbound endpoint can be set on the component directly, which is a little easier than configuring routers.
- Exception Strategies - A single endpoint can be configured on an exception strategy to all events to be sent to an error endpoint.
Mule Event Flow
The nine stages of a mule event
Message Receiver Endpoint
Some Event triggers a message flow. For example
- A file being written into a folder
- A message arriving on a message queue
- A record in a database
- Data written to a socket
Inbound Router
The inbound router is the fist step in a message. Functions typically performed by an inbound router
- Filtering
- Remove duplicate messages
- Matching messages
- Aggregation (combining)
- Re-sequence data
- Forwarding
Interceptor
Used to intercept message flow into your service component or used to trigger monitor/events or interrupt the flow of the message
Example: an authorization interceptor could ensure that the current request has the correct credentials to invoke the service.
Inbound Transformer
If the inbound data is not in the correct format for the service it must be transformed at this point
Service Invocation
The actual service is performed. Service invocation can also be a "pass through"
Outbound Router
Dispatching the data to all the relevant endpoints
Outbound Transformer
Any transformations that needs to be done on the message after a service has been performed on the message can be executed before it is put into the endpoint
There are two code samples attached.
Sample 1 – This is the enhanced version of Stockquote webapp. This example fetches the Stock information the website and dumps into the DB using a JDBC connector.
Sample 2 (EmployeeSync) – This shows a typical data integration scenario using mule. The flow goes as follows.
The canonical Employee is called as the Global Generic Employee is also the source. To create or update an employee Information, we use the StdIn console. Once the data is entered, the control transfers to jBPM engine. jBPM was not a must here. The functionality could have been easily achieved by a custom filter. But I wanted to explore the jBPM integeration with Mule. The jBPM process engine identifies whether it is a Insert or an Update function and sets the appropriate endpoint. The Endpoint Selector appropriately then transfers the control to the corresponding message inbound flow.
If the employee is inserted, then the employee information is propogated to HRDB and payrollDB, which holds subset of cannonical Employee information. The new employee ids generated is stored back in the Global Generic Employee DB.
Conclusion:
Mule can be considered as “Spring for messaging”. In as non-invasive a manner as possible it connects, Java objects with messaging technologies. Mule provides a standard, generic interface to a wide variety of messaging systems. Mule is an enormous and very flexible framework that allows you to build such applications. If you are looking to build an agile business, and don't want to spend the heavy dollars that something like BizTalk, Websphere Message Broker would cost, it is well worth a look.
Next Steps:
This example should help you get started in configuring and extending the Mule enterprise service bus. Hopefully, it would have given you a greater understanding of the principle of how ESB works. Next I shall be posting on my experience with Mule- on a asynchronous long running transaction
Posts
