 |  |  |  |  |
| | | | |
 |  |
One of the biggest challenges facing modern enterprises is IT system integration. FUSE ESB tackles this problem using a lightweight standards based, loosely coupled approach. By relying on standards, FUSE ESB reduces the chances of vendor lock-in. By advocating loose coupling, FUSE ESB reduces the complexity of integration.
Enterprise networks commonly deploy disparate applications, platforms, and business processes that need to communicate or exchange data with each other. The applications, platforms and processes have non-compatible data formats and non-compatible communications protocols. If an enterprise needs to interface with external systems, the integration problem extends outside of a company and encompasses its business partners' IT systems and processes as well.
In recent years, there have been several technologies attempting to solve these problems such as Enterprise Application Integration (EAI), Business-to-Business (B2B). These solutions addressed some of the integration problems, but were proprietary, expensive, and time-consuming to implement. These solutions range from expensive vendor solutions (high cost, vendor lock-in) to home-grown custom solutions (high maintenance, high cost). The overwhelming disadvantages of these solutions are high cost and low flexibility due to non-standard implementations.
Most recently, Service Oriented Architecture(SOA) has become the hot integration methodology. SOA attempts to address the shortcomings of the other approaches by advocating the use of standards and the use of loosely coupled interfaces. While, SOA, theoretically, improves the solution, it can be difficult to implement because vendors are offering tools using proprietary technologies and attempting to wrap old solutions in SOA clothing.
An Enterprise Service Bus(ESB) is the back bone of a SOA implementation. There is no canonical definition of an ESB. Wikipedia opens its entry on ESBs (http://en.wikipedia.org/wiki/Enterprise_service_bus) by stating:
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. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary. | ||
| --Wikipedia | ||
LooselyCoupled defines an ESB as follows:
An ESB acts as a shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure. It supplements its core asynchronous messaging backbone with intelligent transformation and routing to ensure messages are passed reliably. Services participate in the ESB using either web services messaging standards or the Java Message System (JMS). Originally defined by analysts at Gartner, ESB is increasingly seen as a core component in a service-oriented infrastructure. | ||
| --looselycoupled.com | ||
The most common way of defining an ESB is by listing the services it provides. These services include:
transport mediation - not all services that need to be integrated use HTTP or JMS
dynamic message transformation - not all services are going to use SOAP and are unlikely to require the same message structures
intelligent routing
security
An ESB simplifies the complexity of integration by providing a single, standards based infrastructure into which applications can be plugged. Once plugged into the ESB, an application or service has access to all of the infrastructure services provided by the ESB and can access any other applications that are also plugged into the ESB. For example, you could plug a billing system based on JMS into an ESB and use the ESBs transport mediation features to expose the billing system over the Web using SOAP/HTTP. You could also route internal POs directly into the billing system by plugging the your PO system into the ESB.
Most ESB implementations provide all of the services that are used to define an ESB, so it is hard to differentiate ESB implementations based on features. A better way to differentiate between them is to use the following four measures:
Supported deployment / runtime environments
Many ESB solutions are designed to be deployed into application servers, other heavy weight containers, or proprietary runtime environments. These types of ESB solution is ideal for distributed computing. They also contribute to vendor lock-in.
Ideally, an ESB solution should have flexible deployment requirements so that it can be distributed through out an enterprise.
Container / component model
Does the ESB solution use a standardized container model, such as J2EE, JBI, or OSGi, for managing deployed services? Or does it use a proprietary model?
Ideally, an ESB solution should use a standardized container model. Standard models ensure maximum compatibility and lessen the learning curve needed for adoption.
Coupling to other infrastructure components
ESB solutions often leave out infrastructure components like orchestration engines and advanced transports like CORBA. Instead they rely on plug-ins or other components to provided the functionality.
Many ESB solutions require a tight coupling between the ESB and the added components. This means that you are limited to only using the added components supplied by the ESB vendor or must learn complex APIs to extend the ESB yourself.
Ideally, an ESB solution would provide a loose coupling or provide a standardized interface between the ESB and any added components. This allows the ESB to be extended easily and in a flexible manner.
Dependencies
ESB solutions have a lot of moving parts and complex dependencies. Some ESB solutions handle these dependencies by locking themselves into using proprietary solutions for things like security or JMS implementations. Others rely on standardized implementations as much as possible.
Ideally, an ESB solution would only depend on widely available standardized libraries to make dependencies easy to manage.
Based on Apache ServiceMix, FUSE ESB reduces complexity and eliminates vendor lock in because it is standards based and built using best in breed open source technology. It differentiates itself in the following ways:
The FUSE ESB kernel is lightweight and can run on most platforms.
The FUSE ESB kernel uses the OSGi framework to simplify componentization of applications.
The OSGi framework is a newly emerging standard for managing the dependencies between application components. It also provides a standard mechanism for controlling the life-cycle of components.
FUSE ESB supports the Java Business Integration(JBI) specification (JSR 208).
JBI is a well defined standard for packaging, deploying, and managing components deployed to the ESB.
FUSE ESB can be coupled to other infrastructure services over a variety of transport protocols and message formats.
Out of the box, the FUSE ESB supports JMS, HTTP, HTTPS, FTP, XMPP, Web services, and a number of other bindings. In addition, you can easily extend its connectivity options using other components that conform to either the OSGi or JBI specification.
FUSE ESB employs standards as much as possible to limit dependencies.
In addition, FUSE ESB supports event driven architectures. Services deployed into the FUSE ESB container can be fully decoupled and will simply listen on the bus until an appropriate service request arrives. FUSE ESB also supports events that occur outside of the bus. For example, a JMS service can listen on a topic that is hosted outside of the bus and only act when an appropriate message arrives.
| | | |
 |
