Featured White Papers

• Measuring Risk to Improve Java Software Quality
• 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

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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 3 of 7

Event taxonomies and causality

The secret to understanding a given event is to know its cause at the time the event occurred, knowledge often referred to as event causality.Event causality is typically divided into two basic categories:

• Horizontal causality:Both the event's source and cause reside on the same conceptual layer in the architectural stack
• Vertical causality:Both the event's source and cause reside on different conceptual layers in the architectural stack

Vertical causality implies an event taxonomy that remains somewhat constant across different layers of a system, as illustrated by the following list:

• Lifecycle events:Signify changes in an entity's lifecycle, such as stopping or starting a process
• Execution events:Signify runtime occurrences, such as service or component invocations
• Management events:Signify when thresholds have exceeded defined limits or ranges

Horizontal causality implies an event taxonomy that also remains somewhat constant across different layers of a system, as illustrated by the following list:

• System-layer events:Signify system-level activities, such as the creation of a file or the closing of a port
• Platform-layer events:Signify platform-level activities, such as the modification of a datasource or the addition of a new service
• Component-layer events:Signify component-level activities, such as the transformation of a view object or a state-machine transition
• Business-layer events:Signify business-level activities, such as the creation of a user or the removal of an account
• Application-layer events:Signify application-level activities, such as a premium increase or a quote submission

The benefits of event-driven communication within an SOA are currently being realized by a number of ESB frameworks and platforms. One of the most promising of these within the Java development realm is Mule.

Introducing Mule

Muleis an open source ESB-messaging framework and message broker, loosely based on the staged event-driven architecture (SEDA). SEDA defines a highly concurrent enterprise platform in terms of stages (self-contained application components) connected by queues. Mule uses concepts from SEDA to increase the performance of processing events.

Mule provides support for asynchronous, synchronous, and request-response event processing using disparate technologies and transports such as JMS, HTTP, email, and XML-based Remote Procedure Call. Mule can be easily embedded into any application framework and explicitly supports the Spring framework. Mule also supports dynamic, declarative, content-based, and rule-based message routing. Mule facilitates declarative and programmatic transaction support, including XA transaction support. Mule provides a representational state transfer (REST) API to provide Web-based access to events.

The Mule ESB model drives all services in a system over a decoupled, message-communication backbone. Services registered with the bus have no knowledge of other registered services; therefore, each service is concerned with processing only the events it receives. Mule also decouples container, transport, and transformation details from the services, allowing any kind of object to be registered as a service on the bus.