Application integration is the biggest challenge today for many enterprises. Building an Enterprise Service Bus (ESB) is probably the quickest and most cost-effective way to address this challenge. ESB enables building service-oriented architecture (SOA) applications.
Mule is a JEE 1.4-compliant Enterprise Service Bus (ESB) messaging framework. It is a scalable, highly distributable object broker that can seamlessly handle interactions with services and applications using disparate transport and messaging technologies.
POJO services enable the developer to write a service as a simple POJO (Plain Old Java Object), and let Mule do the wiring of that POJO to the network in a declarative manner.
The combination of POJO Services and the Space Based Architecture approach can provide an efficient solution for stateful services. Together with Spring, this combination can turn your POJO into a highly efficient and scalable service, that can dynamically scale across an entire network of machines without any code modifications. Space-based POJO services are particularly suitable for high-performance applications, which need in-JVM optimizations, high availability, high reliability, and possible embedding within applications.
The POJO services approach increases simplicity; allows easy integration with IoC containers; enables declarative orchestration of services; and enables Web-Services automation, which includes WSDL generation, support for stateful services, service export, and invocation plumbing free of charge and increased agility.
Specifically, it enables constructing a powerful integration layer between space services and other parts of the application, allowing arbitrary object transformation, configuration-based content routing, and stateful invocation chains.
Mule is based on a strong event handling paradigm. When applied to Javaspaces, it allows services to subscribe to events in the space and to publish events to a space. The following Mule configuration snippet subscribes all objects placed in a space, and sends the resulting object to a JMS queue:
Notice that the subscription endpoint address uses a gs: scheme. This means that the URL proceeding it will be passed to GigaSpaces to get a reference to the space and register interest on it.
The example above shows how to register interest in all events in a space. However, JavaSpaces uses a template mechanism for selecting which events to receive. You can define these templates in Mule using filters.
To install the GigaSpaces-Mule integration package:
All of the examples under <GigaSpaces Root\mule\examples have the same structure. The bin folder under each example contains the following options:
This example demonstrates a simple space client exposed as a web service working directly with the space API. This example is very similar to the simple example, and shows how an already exposed service (using a space) can also be exposed as a web service.
The client (Main.java) uses the exposed web service (started by the Mule server) and sends an Order to it. The client uses the Mule built-in MuleClient in order to simplify the web service execution. The Mule server receives the Order through the web service using the OrderServiceWS, and invokes the OrderService using the provided Order. The latter takes the Order, 'processes' it (currently just printing a message to the console) and returns an OrderReceipt object. The returned object is written back to the space by Mule, and is then picked up by the initiating client (Main).
The client (Main.java) writes an Order object to the space. Mule picks the Order object via a filtered inbound endpoint, and invokes the pre-registered Order Service Bean. Filtering allows specifying that only orders fulfilling certain business rules will be picked and processed. In our case, the business rule imposed is that the Order's processed attribute is equal to false, designating that the order was not yet processed by the service.
Mule takes the Order and uses it to invoke the Order Service Bean's process() method, which sets the processed attribute to true, prints a message to the console and returns an Order Receipt. The receipt is then written back to the space by Mule, according to the service's outbound definition. The client now takes the order receipt from the space, and verifies that the expected result was received.
The client (Main.java) starts by firing up 3 threads, which constantly write 3 types of objects to the space: OrderRequest, InventoryRequest, and PurchaseRequest. Next, the client fires another 3 threads, each of which take from the space a template based on the corresponding result type: OrderReceipt, InventoryReceipt and PurchaseReceipt. (This scenario is quite similar to the previous example, just with three different types of input and output objects). The Mule server picks up the different request objects using a filtered inbound endpoint, matching the object types this time, and invokes the corresponding Service Beans. The receipt objects returned by these invocations are then written back to the space, according to the outbound endpoint definitions.
This example emphasizes the role of the space filter in telling certain services to take care of certain object types.
The client writes an Order object to the space. This Order object has a phase attribute, initialized to 0. Mule configuration contains 3 different order processor beans (accounting, inventory and shipping), which use a matching template for the inbound endpoint, where phase is specified. The first one takes Orders whose first phase equals to 0, the second – to 1, and the third – to 2. Each processor bean, when done, returns the same Order Bean to the space after expanding its phase attribute by one. Together, these processor beans compose a decoupled processing pipeline, which is configurable through Mule's configuration XML. After being processed by the third processor bean, the Order is taken back by the client, who has been patiently waiting for an Order with a phase attribute value of 3.
In this example, the client writes two StreamEntry implementation objects into the space. The first, FileEntry, is a simple container object for an array of bytes read from a file on disk, and the second, URLEntry, holds a URL object pointing to a resource somewhere on the internet or the intranet (as in the example). One object of each kind is written to space, which is monitored by Mule for StreamEntry implementations. For both objects that are written to space, a StreamConsumerBean is activated, and the Stream contained or referenced by the StreamEntry implementation is read and processed. This example demonstrates a possile usage of a space as a transmission layer for transferring arbitrary chinks of data from one place to another, whether by value or by reference.
We need your help to improve this wiki site. If you have any suggestions or corrections, write to us at email@example.com. Please provide a link to the wiki page you are referring to.