About Mule

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.

Mule Features:

• Powerful Application Integration framework.
• Pluggable connectivity for various protocols, including: JMS, JVM, JDBC, JavaSpaces, TCP, UDP, Multicast, HTTP, servlet, SMTP, POP3, file, XMPP, JBI.
• Orchestration of services using WS-BPEL and Mule components and routers.
• Support for synchronous, asynchronous, and request-response event processing.
• Web Services support.
• Flexible deployment topologies including Client or Server, Peer-to-Peer, ESB and Enterprise Service Network.
• Declarative and programmatic transaction support, including XA support.
• End-to-End support for routing, transport and transformation of events.
• Spring framework integration. Can be used as the ESB container and Mule can be easily embedded into Spring applications.
• Highly scalable enterprise server using the SEDA processing model.
• REST API to provide technology agnostic web-based access to Mule events.
• Dynamic, declarative, content-based and rule-based routing options.
• Non-intrusive approach. Any object can be managed by the ESB container.
• Fully extensible development model.

New in GigaSpaces 5.2.1 The GigaSpaces-Mule integration package is new in GigaSpaces version 5.2.1 and onwards.

The GigaSpaces-Mule integration package can be downloaded here. For details on how to install it, see below.

Lightweight ESB – Space-Based POJO Services

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.

GigaSpaces-Mule Feature Set

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:

<mule-descriptor
	name="unprocessedOrders"
	implementation="com.foo.ProcessingComponent">

    <inbound-router>
        <endpoint
		address="gs:java://localhost/mule-space_container/mule-space?schema=cache"/>
    </inbound-router>

    <outbound-router>
        <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
            <endpoint address="jms://processed"/>
        </router>
    </outbound-router>

</mule-descriptor>

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.

Using Templates

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.

<mule-descriptor name="unprocessedOrders" implementation="com.foo.ProcessingUMO">
  <inbound-router>
    <endpoint address="gs:java://localhost/mule-space_container/mule-space?schema=cache">
      <filter
        className="org.mule.providers.gs.filters.GigaSpacesTemplateFilter"
        expectedType="com.foo.Order">

          <properties>
            <map name="fields">
              <property name="processed" value="false"/>
            </map>
          </properties>
      </filter>
    </endpoint>
    </inbound-router>

    <outbound-router>
      <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
        <endpoint address="jms://processed"/>
      </router>
    </outbound-router>
</mule-descriptor>

The example above shows how to configure a filter to receive events of type com.foo.Order, and where the processed property of the Order object is false.

Installing GigaSpaces-Mule Integration Package

To install the GigaSpaces-Mule integration package:

1. Download the GigaSpaces-Mule integration package.
2. Extract the downloaded zip file into your <GigaSpaces Root> directory.
3. A directory called mule appears in your <GigaSpaces Root> directory.

Examples Description

All of the examples under <GigaSpaces Root\mule\examples have the same structure. The bin folder under each example contains the following options:

• Compiling the example by executing compile.bat or sh.
• Running the example:
  • Start a space by executing startServer.bat or sh, and then run the example by executing run.bat/sh.
  • Alternatively, execute run_embedded.bat or sh – runs the example using an embedded space.

Web Service (codebase: webservice)

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).

Simple Request-Response Messaging (codebase: simple)

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.

Request-Response Messaging with Content Routing (codebase: content-routing)

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.

Pipeline Processing (codebase: pipeline)

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.

Streaming Through Space (codebase: streaming)

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.