The goals of the Mule project and Universal Message Objects have
been heard before a thousand times although not necessarily delivered
together (or even delivered!) -
* Scalable messaging framework that should handle most of the complexities of systems integration.
* Easy to use, yet powerful server that can operate over complex topologies.
* Simple Autonomous component development and deployment
* Code reuse. If all components are self-contained, independent units of work they can be plugged into any other system
* Rapid time to market. Using Mule will provide time-saving
features and functionality with no development or maintenance overhead
* Flexible. A powerful configuration that should be easy to manage over a distributed environment.
When the Mule project started there seemed to be a gap in the market
for a simple and lightweight way to write components that do something
to data without needing to worry about the sender or recipient of the
data, the format of the data or the technology being used to
send/receive the data. The key feature here is "simple"; although many
brokering and integration technologies offer the ability to connect to
disparate data sources, you often have to do extra coding to get it to
behave the way you want and to deliver the data where you want it to
go. Mule allows you to quickly develop components and then change the
way they behave through configuration instead of coding.
Mule is in no way a replacement for existing application framework.
In fact Mule leverages many open source projects such as Axis, Spring,
ActiveMQ, Plexus and PicoContainer. Mule fills a void in enterprise
java development where an application requires complex interactions
with a variety of systems on a variety of platforms. Mule makes light
work of wiring these systems together in a robust decoupled environment
and provides the necessary support to route, transport and transform
data to and from these systems.