Below are notes I took while attending Tom Bender's talk on Mule at the Colorado Software Summit:
SOA: A collection of services with well-defined interfaces and a shared communication model is called a service-oriented architecture.
ESB: Provides a light weight, loosely coupled, event-driven SAO with a highly distributed universe of naming routing destinations across a multi-protocol message bus.
Four Tenets of SAO (as proposed by Don Box):
- Boundaries are Explicit
- Services are Autonomous
- Services share Schema and Contract, not Class
- Compatibility is based upon Policy
Properties of an ESB: Light Weight, Loosely Coupled, Event-Driven, Transactional, Securable, Distributed Network Topologies, Abstract Endpoints, Intelligent Routing, Message Transformation (inbound/outbound), Multi-Protocol Message Bus.
One of the main differences between application servers and ESBs is appservers are traditionally integrated with a hub-and-spoke architecture. ESBs, on the other hand, use a distributed integration architecture.
Mule - What is it?
Ross Mason is the founder and primary developer of Mule. From its homepage:
Mule is an 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 is an event-based architecture. Actions within a Mule network are triggered by either events occurring in Mule or in external systems. It's a light-weight messaging framework that's highly distributable and very pluggable (i.e. for multiple transports and protocols). Mule supports Web Services using Axis or Glue.
A Closer Look at Mule
The basic building block is a "UMO Component". This component is used to wire applications together - it's basically a POJO that can optionally implement interfaces if it wants to hook into lifecycle events. An application communicates with the UMO component through a channel (i.e. TCP/IP or JMS). This channel talks to a message receiver that works with a connector that's backed by a transformer and formats it for the UMO component (whoa, that's a mouthful - and that's only inbound!). When going to the receiving application, the process starts from the UMO component, goes though the outbound router - and plows through the whole transformer » connector » message dispatch » channel » application process again. Here's a diagram of this process that I found on Mule's website:
Mule supports many different endpoints: POP3/SMTP, JMS Topic or Queue, HTTP, File, VM (w/in the JVM), SOAP, RMI and EJB. Each of these have their own URI prefix.
I tuned out for the rest of Tom's talk (sorry Tom). The whole ESB topic is pretty dry IMO, but Tom seemed to do a good job of keeping the audience interested.