What is JBI ?

Java Business Integration (JBI) is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA).
The JCP reference is:
JBI 1.0 – JSR 208
JBI 2.0 – JSR 312
Following open-source JBI implementations are available

• Open ESB
• Petals ESB
• Apache ServiceMix
• FUSE ESB (enterprise ServiceMix) – compliant JSR 208
• Bostech ChainBuilder ESB
• Mule. Though not a JBI compliant container by itself, Mule provides interoperability with JBI containers. There is a separate Mule-JBI project that is to address this JBI compliance issue.

JBI is built on a Web Services model and provides a pluggable architecture for a container that hosts service producer and consumer components. Services connect to the container via binding components (BC) or can be hosted inside the container as part of a service engine (SE). The services model used is Web Services Description Language 2.0. The central message delivery mechanism, the normalized message router (NMR), delivers normalized messages via one of four Message Exchange Patterns (MEPs), taken from WSDL 2.0:

1. In-Only: A standard one-way messaging exchange where the consumer sends a message to the provider that provides only a status response.
2. Robust In-Only: This pattern is for reliable one-way message exchanges. The consumer initiates with a message to which the provider responds with status. If the response is a status, the exchange is complete, but if the response is a fault, the consumer must respond with a status.
3. In-Out: A standard two-way message exchange where the consumer initiates with a message, the provider responds with a message or fault and the consumer responds with a status.
4. In Optional-Out: A standard two-way message exchange where the provider’s response is optional.

JBI Basics

* Messaging based, plug-in architecture
* This infrastructure allows third-party components to be plugged in” to a standard infrastructure, and allows those components to interoperate
* It does not define the pluggable components themselves, but the container/framework interfaces, behavior and services
* Is itself a service-oriented architecture
* Components describe their capabilities via WSDL
* Key components
o Service Engines (SE) – pluggable business logic
o Binding Components (BC) – pluggable external connectivity
o Normalized message router (NMR)

Service Engine (SE)

* Container for hosting Service Units that provide Business Logic.
* These provide an abstract WSDL interface to describe the service.
* The SU is exposed as an endpoint on the NMR.
o Examples include: BPEL SE, JavaEE SE, IEP SE, POJO SE, JRuby SE

Binding Component (BC)

* Container for hosting Service Units that define external connectivity.
* The SU is exposed as an endpoint on the NMR
* BCs expose a WSDL-described interface to other SUs.
* BCs expose a protocol-specific interface to clients and systems that are external to environment.
* BCs map outgoing requests from a service invocation from another SU to protocol specific invocation to an external system
* BCs map incoming requests from a protocol specific invocation from an external system to a service invocation of another SU.
o Examples include: JMS BC, HTTP BC, REST BC, Email BC

Service Units and Service Assemblies

* primary unit of functionality in JBI
* Service Units (SU) can be deployed to installed BCs and SEs
o This allows the deployment (and undeployment) of component-specific artifacts (e.g. concrete WSDLs)
o Can describe what services are provided and consumed by the component
o Besides the standard descriptor, the component is responsible for interpreting the contents of the SU jar
* A Service Assembly (SA) can package multiple service units and defines the target components to deploy them to

Normalized Messages

* Standard format forms the foundation of the interoperability between JBI components
* The primary content of a normalized message is always XML
* There are two distinct parts to a normalized message
o Content – the message data, as described by the abstract WSDL (represented as an XML transform Source, e.g. DOM or SAX Source)
o Context (Meta-data in message properties, such as a security subject or protocol headers)

For latest openesb updates, visit the link at : http://www.logicoy.com/openesb