Mule - The Open Source Enterprise Integration Solution, Page 2
Mule ComponentsIn order to appreciate the value of Mule and use it effectively, you would need to understand its architecture and core components. This section attempts to provide a glimpse into the important Mule components.
ModelModel is like a container that manages the services. A model can contain any number of services and it allows a service to talk to another service.
Inbound routerInbound routers specify how messages are routed to the service. The service can typically have any number of inbound routers. For example, one router may listen to HTTP and another one may listen to SOAP and so forth. Mule has lots of built-in inbound routers and hence the user will have to just configure the right router that he/she wants to use.
Service componentThe service component can be of any type, from a POJO to an object in another framework, for example "Spring". An important note here is that the component does not need to contain any Mule specific code.
Outbound routerThe outbound router will route the message to the next application. The routing of outbound messages may be controlled using Filters.
FiltersFilters control the routing of the message to the appropriate destinations. It specifies conditions which should be met by the message in order to get routed to a particular destination.
TransformersTransforms transform data from one format to another format. They are required when the format/type of received data is different from what the service component expects. There are lots of built-in transformers within Mule. The user can also build his/her own transformers using the Mule Transformer APIs.
The following figure will show you the core components of a Mule service. Please note that for clarity purpose, only one service is shown in the Model. But in the real case, there can be more than one service within the Model.
Mule's features give it the edge over its competitors. The features list includes but not limited to:
- Mule service components can be of any type; from a POJO class to an object managed in another framework like spring
- Existing components can be used as such without any change. Components do not need to contain any mule specific code.
- Business logic (i.e., payload) is separated from the messaging logic that routes the payload between different applications.
- Message can be of any type (POJO, Spring, etc.) and not necessarily as a SOAP message.
- There is no vendor lock-in as Mule does not depend on a particular vendor and it can be integrated with any vendor infrastructure.
- It provides connectivity over several protocols; HTTP, SOAP, JMS, SMTP, FTP, POP3 and many more.
- It is content based and rules based routing.
- It supports integration with Spring and BPM.
Sample - Expose POJO as Axis Web ServiceLet's see how we can easily implement a sample scenario using Mule that would exemplify the core components such as routers and service components. The scenario is about a "Portfolio Manager" that manages stock market investor's stock portfolio.
Though there may be better way of implementing this, this sample implementation however aims to use a single component that is implemented as POJO and expose it over Axis Web Service. For benefit of understanding, Axis belongs to Apache Community and is a SOAP messaging framework that provides platform to develop web services and client utilities. For more information on Axis, please read http://ws.apache.org/axis.
InstallationYou are required to download and install Mule for executing the sample programs. The binaries can be downloaded from this link http ://www.mulesource.org/display/MULE/Download. The installation of Mule is as simple as extracting the zip file into your local directory. Mule version 2.1.2 is what we used in implementing this sample.
ConfigurationIn order to expose as a service, you would need to choose an inbound router, service component and an optional outbound router. As Mule separates the data from messaging, coding is not required mostly and most of the work can be achieved using configurations itself. The following configuration shows how you can configure inbound and outbound routers along with the service component.
<mule > <custom-transformer name="LoginStatusToStringUsername" class="samples.utils.LoginStatusToStringUsername"/> <service name="PortfolioService"> <inbound> <axis:inbound-endpoint address="http://localhost:7070/services"/> <stdio:inbound-endpoint system="IN" /> <vm:inbound-endpoint path="portfolio" transformer-refs="LoginStatusToStringUsername"/> </inbound> <component class="samples.services.PortfolioManager"/> <outbound> <pass-through-router> <stdio:outbound-endpoint system="OUT"/> </ pass-through -router> </outbound> </service> </mule>
The above xml file configures a service, namely, "PortfolioService". The service component is just a POJO class, named 'samples.services.PortfolioManager'. It uses three inbound routers to receive requests from other applications.