Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Event-driven services in SOA

Design an event-driven and service-oriented platform with Mule

By Jeff Hanson, JavaWorld.com, 01/31/05

Page 5 of 7

Mule model

A Mule model encapsulates and manages the runtime behavior of a Mule server instance. A model consists of:

• Descriptors
• UMO components
• An endpoint resolver
• A lifecycle-adapter factory
• A component resolver
• A pool factory
• An exception strategy

Mule manager

The Mule manager maintains and provides the following services:

• Agents
• Providers
• Connectors
• Endpoints
• Transformers
• The interceptor stack
• A Mule model
• A Mule server
• The transaction manager
• Application properties
• The Mule configuration

The diagram in Figure 2 illustrates a high-level view of the message flow for the Mule architecture.

Figure 2: Mule high-level architecture. Click on thumbnail to view full-sized image.

Mule events

Mule events contain event data and properties examined and manipulated by event-aware components. The properties are arbitrary and can be set at any time after an event is created.

The org.mule.umo.UMOEvent class represents an event occurring in the Mule environment. All data sent or received within the Mule environment is passed between components as an instance of UMOEvent. The data in a Mule event can be accessed in its original format or in a transformed format. A Mule event uses a transformer associated with the provider that received the event to transform the event's payload into a format the receiving component understands.

The payload for a Mule event is contained within an instance of the org.mule.umo.UMOMessage interface. A UMOMessageinstance is composed of the payload itself and its associated properties. This interface also acts as a common abstraction of different message implementations provided by different underlying technologies.

The org.mule.extras.client.MuleClient class defines a simple API that allows Mule clients to send and receive events to and from a Mule server. In most Mule applications, events are triggered by some external occurrence, such as a message received on a topic or a file being deleted from a directory.

The following illustrates how to send an event synchronously to another Mule component:

                    String componentName = "MyReceiver"; // The name of the receiving component. 
String transformers = null; // A comma-separated list of transformers
                            // to apply to the result message. 
String payload = "A test event"; // The payload of the event. 
java.util.Map messageProperties = null; // Any properties to be associated
                                        // with the payload.
MuleClient client = new MuleClient();
UMOMessage message = client.sendDirect(componentName,
                                       transformers,
                                       payload,
                                       messageProperties);
System.out.println("Event result: " + message.getPayloadAsString());
               

An instance of MuleClient requires a server URL to define the endpoint for the remote Mule server to which the MuleClientinstance will connect. The URL defines the protocol, the message's endpoint destination, and, optionally, the provider to use when dispatching the event. Endpoint examples are:

• vm://com.jeffhanson.receivers.Default:Dispatches to a com.jeffhanson.receivers.Default destination using the virtual machine provider. The VM provider enables intra-VM event communication between components using transient or persistent queues.
• jms://jmsProvider/accounts.topic:Dispatches a JMS message via the globally registered jmsProvider to a topic destination called accounts.topic.
• jms://accounts.topic:Dispatches a JMS message via the first (default) JMS provider.

Mule event processing

Mule can send and receive events in three different ways: