IT system integration is one of the biggest challenges facing modern enterprises. Fuse ESB Enterprise tackles this problem using a lightweight standards-based, loosely-coupled approach. By relying on standards, Fuse ESB Enterprise reduces the chances of vendor lock-in. By advocating loose coupling, Fuse ESB Enterprise 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. These entities typically use incompatible data formats and incompatible communications protocols. For an enterprise that needs to interface with external systems, the problem extends outside the company to encompass the IT systems and processes of its business partners.
In recent years, several technologies, such as Enterprise Application Integration (EAI) and Business-to-Business (B2B), have attempted to solve these problems. These solutions addressed some of the problems of integration, but were proprietary, expensive, and time-consuming to implement. They ranged from expensive vendor solutions to home-grown custom solutions. The overwhelming disadvantages of these solutions were high cost and low flexibility due to nonstandard implementations.
Most recently, Service Oriented Architecture (SOA) has become the hot integration methodology. SOA attempts to address the shortcomings of the previous approaches by advocating the use of standards and loosely-coupled interfaces. While SOA theoretically improves on those solutions, it can be difficult to implement because many vendors offer tools that use proprietary technologies and attempt to wrap old solutions in SOA clothing.
An enterprise service bus (ESB) is the back bone of an SOA implementation. Though no canonical definition of an ESB exists, David Chappell states in his book Enterprise Service Bus:
The term extended enterprise describes an organization and its business partners, who are separated by both business and physical boundaries.
An ESB is typically defined by the list of services it provides. Services commonly included are:
Transport mediation—not all applications and services that need to be integrated use HTTP or JMS.
Dynamic message transformation—not all services use SOAP and are unlikely to require the same message structures.
Intelligent routing—not all messages emanating from a source are intended for the same destination. The target destination will likely depend on some criteria inherent in the message.
Security—only authorized and authenticated users need have administrative access to the Fuse ESB Enterprise runtime; services and brokers that handle sensitive information may restrict access to unauthorized or unauthenticated clients only; similarly, messages that contain sensitive information may be encrypted as they transit their routes.
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 purchase orders directly into the billing system by plugging the Purchase Order 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. Though these solutions support distributed computing, they also contribute to vendor lock-in.
Ideally, an ESB solution should have flexible deployment requirements, so it can be distributed throughout an enterprise.
Container/component model
Does the ESB solution use a standardized container model, such as JEE or OSGi for managing deployed services? Or does it use a proprietary model?
Ideally, an ESB solution should use a standards-based container model. Standard models ensure maximum compatibility and decrease the learning curve needed for adoption.
Coupling to other infrastructure components
ESB solutions often omit infrastructure components, such as orchestration engines and advanced transports like CORBA. Instead they rely on plug-ins or other components to provide that functionality.
Many ESB solutions require a tight coupling between the ESB and added components. This means that you are limited to using only added components supplied by the ESB vendor or that you must learn complex APIs to extend the ESB yourself.
Ideally, an ESB solution should provide a loose coupling between the ESB and added components or provide a standardized interface between them. This approach allows the ESB to be extended easily and in a flexible way.
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. Others rely on standards-based implementations as much as possible.
Ideally, an ESB solution should depend only on widely available standardized libraries to make dependencies easy to manage.
Based on Apache ServiceMix, Fuse ESB Enterprise reduces complexity and eliminates vendor lock-in because it is standards-based and built using best-of-breed, open source technology. It differentiates itself in these ways:
Fuse ESB Enterprise is lightweight and can run on most platforms.
Fuse ESB Enterprise uses the OSGi framework to simplify componentization of applications.
Fuse ESB Enterprise provides a mechanism, Fuse Application Bundle (FAB), that automates creating and maintaining OSGi bundles.
FABs free application developers from the complexities associated with creating and maintaining OSGi bundles, enabling them to focus on building their applications. This is especially useful when you are developing large, complex enterprise applications. See FABs in a nutshell.
Fuse ESB Enterprise supports the Java Business Integration (JBI) specification (JSR 208).
Fuse ESB Enterprise can be coupled to other infrastructure services over a wide variety of transport protocols and data formats.
Out of the box, the Fuse ESB Enterprise supports JMS, HTTP, HTTPS, FTP, XMPP, Web services, and a number of other bindings. In addition, you can easily extend its connectivity options using routing and integration components.
Fuse ESB Enterprise employs standards as much as possible to limit dependencies.
Fuse ESB Enterprise supports event-driven architectures. Services deployed into the Fuse ESB Enterprise container can be fully decoupled and will simply listen on the bus until an appropriate service request arrives. Fuse ESB Enterprise also supports external events that occur outside the bus. For example, a JMS service can listen on a topic that is hosted outside the bus and act only when an appropriate message arrives.
OSGi is set of open specifications that make it easier to build and deploy complex software applications. The OSGi Framework, the key piece of OSGi technology, is responsible for loading and managing the dynamic modules of functionality, otherwise known as bundles (see Building an OSGi Bundle in Deploying into the Container).
In an OSGi environment, applications are packaged into bundles—jar files that contain extra information about the classes and resources included in them. The information supplied in a bundle includes:
Packages required by classes in the bundle
Packages the bundle exports
Version information for the bundle
Using this information, the OSGi framework checks that all of the dependencies required by the bundle are present. If they are, the bundle is activated and made available. The information included in a bundle also enables the OSGi framework to manage multiple versions of it.
Among the advantages OSGI offers over other container and packaging models are:
A FAB is a jar file created using Apache Maven or similar build tool. It contains a
pom.xml file located in
META-INF/maven/<groupID>/<artifactID>/. The pom.xml
file declares all of the jar's transitive dependencies. (See Using Apache Maven.)
When a FAB is deployed in Fuse ESB Enterprise, the runtime converts it into a normal OSGi bundle, then
extracts and uses the jar's pom.xml file to identify its transitive dependencies.
This process enables the runtime to generate one or more OSGi bundles according to how the
dependencies are listed in the pom.xml file. Unless already installed, Fuse ESB Enterprise
automatically installs all identified transitive dependencies.
A FAB can depend on regular jars or OSGi bundles, and it can install, start, stop, and uninstall its transitive dependencies.
For details, see Building a FAB in Deploying into the Container and Deploying a FAB in Deploying into the Container.
 |  | |
 |
