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.
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
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.
Ideally, an ESB solution should use a standardized container model, such as J2EE, JBI, or OSGi, for managing deployed services.
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.
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.
The Fuse ESB kernel is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.
Hot deployment: When a JAR file is added to the InstallDir/deploy folder, it is automatically installed inside the runtime.
Provisioning: Application provisioning through file-drop, Maven repository and remote download.
Dynamic configuration: Changes to the properties files contained in the InstallDir/etc directory are monitored and propagated to the relevant services.
In an OSGi environment applications are packaged into bundles. A bundle is a JAR that contains extra information about the classes and resources included in the bundle. The information supplied in the bundle includes:
* packages required by classes in the bundle
* packages being exported by the bundle
* version information for the bundle
The information in the bundle also allows the framework to manage multiple versions of a bundle.
# Hot deployment of artifacts
# Management of multiple versions of a package, class, or bundle
# Dynamic loading of code
Karaf supports the following OSGi 4.2 containers:
* Apache Felix Framework 2.0.0
* Eclipse Equinox 3.5.
In Fuse ESB 4.3, the default container is Equinox. To change your OSGi container, set the karaf.framework property to felix in the etc/config.properties file.
You can deploy Java Business Integration (JBI) 1.0 service assemblies and service units in Fuse ESB.
Apache ActiveMQ message brokers can be deployed and managed as OSGi bundles.
You can deploy JAX-WS and JAX-RS RESTful web services built using Apache CXF.
You can add any Spring configuration file to the deploy directory and Fuse ESB will generate an OSGi bundle on the fly and instantiate the Spring application context.
You can implement enterprise integration patterns in Apache Camel and deploy them in Fuse ESB.
The Fuse ESB console is a shell environment, based on Apache Felix Gogo, that enables you to control the Fuse ESB runtime.
The command console provides subshells to manage artifacts, including OSGi bundles, collections of bundles, JBI artifacts, and OSGi bundle repositories (OBRs).
/etc—kernel and bundle configuration files
/system—contains the OSGi bundles to be installed at runtime, organized as a Maven 2 repository. By default, Fuse ESB first checks this folder when resolving a required artifact, before checking the user’s local Maven repository.
A feature is a named, versioned collection of OSGi bundles that work together to provide some functionality.
You can specify the features that Fuse ESB installs when it first starts up and the initial set of registered feature URLs using the etc/org.apache.karaf.features.cfg file.
Fuse ESB uses the OPS4j Pax Logging system, a standard OSGi logging service that also supports the following APIs:
* Apache Log4j
* Apache Commons Logging
* Java Util Logging
By default, Fuse ESB installs and activates support for Spring Dynamic Modules (Spring DM), which integrates Spring with the OSGi container. This means that it is possible for you to include Spring configuration files, META-INF/spring/*.xml, in your bundle. One of the key consequences of having Spring DM enabled in the OSGi container is that the lifecycle of the Spring application context is automatically synchronized with the OSGi bundle lifecycle:
* Activation—when a bundle is activated, Spring DM automatically scans the bundle to look for Spring configuration files in the standard location (any .xml files found under the META-INF/spring/ directory). If any Spring files are found, Spring DM creates an application context for the bundle and creates the beans defined in the Spring configuration files.
* Stopping—when a bundle is stopped, Spring DM automatically shuts down the bundle’s Spring application context, causing any Spring beans to be deleted.