Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
minLevel2
maxLevel6

Overview

What is JBI ?

Info
titleA Brief Intro to JBI

A brief introduction to JBI is available in the What is JBI? document. This document is more in-depth and supplemental.

Section

JBI is a java based standard to build integrations systems by using plug-in components which interoperates through mediated normalized message exchanges.
The message exchange model is based on the web services description language (WSDL).

The figure at the top shows a high level concept of JBI of the plug-in framework. The JBI environment provides interfaces to be used by plug-in components, while the components provides interfaces used by the JBI environment. Components do not interact with each other directly. Instead, as shown in the bottom figure, JBI acts as an intermediary to route messages between components. This separation is the key to decoupling between service providers and consumers, which is one of the goal of service oriented architectures. In addition, it provides a key point for message processing and monitoring.

Panel
borderColor#ccc
bgColor#ffffff
titleJBI plugin framework
borderStylesolid

Image RemovedImage Added

Panel
borderColor#ccc
bgColor#ffffff
titleJBI decoupling
borderStylesolid

...

Section
Column

This picture describes the architecture of the JBI system.

  • The JBI environment provides deployment, control & monitoring features through JMX based administration tools
  • The Normalized Message Router or NMR, which provides the mediated message exchange infrastructure
  • Components (in white rectangles)

Components are divided in two categories:

  • Service Engines (on top) provides business logic and transformation services and also consumes such services.
  • Binding Components provide connectivity to services external to the JBI environment.
    Service engines and binding components can function as service providers, consumers, or both. Note that the distinction between SEs and BCs is purely pragmatic, but the separation of business logic from communications logic reduces complexity and increases flexibility.
Column
Panel
borderColor#ccc
bgColor#ffffff
titleJBI Architecture
borderStylesolid

Image RemovedImage Added

The JBI environment, in addition to the messaging system, defines a management structure based on JMX which provides standard mechanisms for:

...

Section
Column

JBI components (Service Engines and Binding Components) can act as a service consumer, a service provider or both. The diagram to the right outlines this using the example of a ServiceMix HTTP Consumer BC and a ServiceMix HTTP Provider BC. Notice where requests are initiated and the direction of the arrows to denote the flow from the initiator.

The provider makes a WSDL-described service available through an endpoint. This service implements a WSDL interface, which is a collection of operations.
The consumer can invoke the service by creating a message exchange that invoke a particular operation.
Consumers and providers only share the abstract service definition and are thus decoupled, as the consumer does not know the protocol and location of the invoked service.
Several services can implement the same WSDL interface so a consumer looking providers of an interface may find more than one endpoint.

Column
Panel
borderColor#ccc
bgColor#ffffff
titleConsumers vs. Providers
borderStylesolid

Normalized message

Section
Column

JBI uses the concept of a normalized message for interactions between consumers and providers.
A normalized message consists of three parts:

  • A payload, which is an xml document that conforms to a WSDL message type without any protocol or encoding
  • Properties (or metadata) holds extra data associated with the message (security, transactions ...)
  • Attachments are arbitrary (non-xml) data that contain a data handler to manipulate them
Column
Panel
borderColor#ccc
bgColor#ffffff
titleJBI Normalized Message
borderStylesolid

Image Added

Delivery Channel

A Delivery Channel is a bidirectional asynchronous communication pipes between a component and the NMR.
A service consumer uses its delivery channel to initiate a service invocation, while the provider uses its delivery channel to receive such invocations.
Each component is provided with a single delivery channel, so the same channel is used for both inbound and outbound communications.

...

People may wonder why there is a need for a "done" status... In JBI, all exchanges are terminated by either a "done" or an "error" status. Errors are different from faults which are parts of the normal exchange processing. So, the done status is very useful to implement reliable message, transactions or passing streams inside the exchange.
Let's take the example a file binding component, which would poll for files, send the content as an InOnly request, and delete them afterwards. For performance reasons, it will send an opened stream on the file, but it has to close the stream and delete the file once processed. If the consumer is asynchronous (which is better because it saves threads), it needs a way to know when the file has to be deleted, hence the need for the "done" status.

#top

JBI packaging

Section
Column

JBI defines a standard packaging for installing new components and deploying artifacts onto these components that can function as "containers".
All these artifacts contain a JBI descriptor in the META-INF directory called jbi.xml.

Column
Panel
borderColor#ccc
bgColor#ffffff
titleJBI Packaging
borderStylesolid

Image Added

We have already discussed some of these artifacts, but let's dive in them a bit more. There are four types of artifacts, all packaged as zip or jar files:

...