Mule - The Open Source Enterprise Integration Solution
Mule - The Open Source Enterprise Integration Solution?
BackgorundService Oriented Architecture (SOA) is a new architectural approach for building distributed systems that deliver application functionality as loosely coupled services. Till recently it was mere hype, but today it's a reality. The use of SOA has been moved from the laboratory level to enterprises level in order to seamlessly integrate disparate applications and create a common platform for carrying out mission critical business processes for the enterprises. The large enterprises are looking at SOA to maximize their returns by reducing complexity and cost of change and improving the leverage & reuse of assets within and outside the enterprise.
In order for enterprises to realize the benefits of SOA, the enterprises will need a robust infrastructure like Enterprise Service Bus (or simply ESB). What is an ESB? Wikipedia says "An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code". The ESB forms the backbone of the SOA system and provides necessary infrastructure for building SOA applications. It acts as a transit system or bus through which different applications talk to each other using different protocols and message formats.
ArchitectureIn order for us to call something an ESB, it should have some basic components and provide certain services. The following figure shows a typical ESB model. It contains enterprise data and applications which are virtualized and exposed to the external world as secured business processes and shared services.
Having set the context of ESB, this article attempts, in a high level, to provide a peek into certain issues with commercial ESBs and how "open source" ESBs such as Mule may be entrusted to do the required job.
Issues with Commercial ESB ProductsSeveral major vendors provide implementations for ESB in the market as part of their SOA suites. However, these products are the evolution of their existing messaging products or extensions of their application servers. To put it simply, the vendor ESB implementations depend on their other propietary infrastructure and will lock in the customer forever. These products have been architected in a way that integration with other vendor's products is difficult and sometimes it may not be possible at all.
SOA is an architectural style and is not a product. However, vendors have been focusing on promoting their products in the SOA space instead of relying on SOA principles. Hence, the right selection of products is a must if you want to realize the full benefits of SOA. Otherwise, the enterprises will end up only in implementing what is popularly known as "Vendor Driven Architecture (VDA)".
Meantime, the commercial ESB products are often quite expensive. They provide turnkey solutions such as adapters for several legacy and today's other major enterprise integration issues. However, these products come with a high price tag.
Mule - Open Source ESB
Introduction to MuleOne alternative for commercial ESB could be a reliable, open source ESB. In the market, there are several open source products available that compete not only within the open source community but also with commercial ones. Mule ESB is one of the most prominent ESB products in the open source category and also claims to be the most used in the open source ESB product category.
Mule is open source, well documented, tried and tested. It is vendor neutral and can be plugged into any number of vendor implementations. It comes with built-in support for lots of protocols such as HTTP, JMS, SOAP, SMTP and many more. With the robust architecture that Mule has, it supports seamless integration of applications of different natures.
Different real world applications use different protocols and message formats. This can make the application integration really difficult. In order to solve this integration problem, Mule provides a framework that converts data into messages that get routed to other applications and the entire thing is controlled through configurations. The real advantage of this framework is that it separates the business logic (usually implemented by enterprises) from the messaging logic that is responsible for routing messages between applications. When the destination application needs a different message format, Mule uses constructs called "Transformations" that transforms the message from source format to destination format.
Mule also comes with lots of pre bundled transformers like XSLT. It also allows developers to plug in their own transformers within Mule context.
The following diagram shows a sample integration of applications that use different technologies and message formats.
Page 1 of 4