What is JBI?

The Java Business Integration spec (JBI) is a Java-based standard that defines a runtime architecture for plugins to interoperate via a mediated message exchange model. This mediated message exchange model was simply adopted from the WSDL 2.0 spec's message exchange patterns (MEPs). Messages between components are mediated by the Normalized Message Router (NMR). The NMR serves as an intermediary for routing messages amongst plugins, no matter where that component resides. Plugins do not communicate directly with one another; they only communicate with the NMR. This provides location transparency for the plugins.

JBI Components

The plugins mentioned above come in two flavors, binding components and service engines. Sometimes it makes more sense to refer to them simply as bindings and engines. Binding components and service engines are generically referred to as JBI components. JBI components are deployed to the JBI environment and simply run in memory waiting for a configuration (more on this below in the section named Using JBI Components).

Binding Components

A binding component (BC) has two purposes:

  1. To communicate using remote protocols
  2. To normalize/denormalize messages it receives

BCs are used to communicate outside the JBI environment. Examples of remote protocols provided by BCs include HTTP/S, JMS, FTP, SMTP, XMPP, RMI, CORBA, etc.

Examples

Some examples of binding components in ServiceMix include:

Message Normalization

Message normalization/denormalization is the act of converting a message from/to a protocol-specific format into a format for the JBI environment. This normalization is performed by BCs involves converting all messages into a NormalizedMessage. A normalized message consists of the following:

  • Content The XML payload message
  • Attachments Extra (generally binary) attachments to the main message object
  • Security Subject The security subject associated with the content
  • Properties Other message-related key/value pairs

There is no canonical message format for JBI. Messages simply must be normalized to meet the criteria above.

Service Engines

A service engine (SE) provides some type of logic inside the JBI environment and only communicates with the NMR. If a SE needs to communicate outside the JBI environment, it must send a message to a BC (via the NMR). Examples of SEs include rules engines, BPEL engines, XSLT engines, scripting engines, EJB containers, etc.

Examples

Some examples of service engine components in ServiceMix include:

Using JBI Components

JBI components are most typically provided to you with the JBI container and they provide support for some of the most common protocols and engines. In order to make use of these components as an application developer, you must provide a configuration for each component you want to use. Configurations are implementation specific but the packaging is defined by the JBI spec. Each component configuration must be packaged as a service unit (SU) (see What is a JBI SU and how do I create one?) and each SU must be wrapped in a service assembly (SA) (see What is a JBI SA and how do I create one?). These are simply ZIP/JAR files that contain a XML descriptor named jbi.xml that is used by the JBI environment. For those folks who are familiar with Java EE development, these ZIP files are similar to WARs and EARs.

Should I Create My Own JBI Components?

Upon first encountering JBI, some folks assume that they need to begin writing their own components. You might, in fact, need to do this, but understanding why you would need to do this is an important first step. To understand why, read the following FAQ entry:

Additional Reading

The following articles are highly recommended follow-up reading to the information on this page:

  • No labels