JBI Introduction

• The JBI 1.0 (JSR-208) specification is an industry-wide initiative to create a standardized integration platform for Java and business applications.
• JBI addresses service-oriented architecture (SOA) needs in integration

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
  • Service Engines (SE) - pluggable business logic
  • Binding Components (BC) - pluggable external connectivity
  • 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.
  • 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.
  • 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
  • This allows the deployment (and undeployment) of component-specific artifacts (e.g. concrete WSDLs)
  • Can describe what services are provided and consumed by the component
  • 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

JBI High-level architecture

Message Exchange Example

• Message exchange patterns supported out of the box are: One-way, Reliable One-way, Request-Response, Request Optional-Response

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
  • Content - the message data, as described by the abstract WSDL (represented as an XML transform Source, e.g. DOM or SAX Source)
  • Context (Meta-data in message properties, such as a security subject or protocol headers)

Lifecycles controlled by JBI Framework

• Binding Components and Service Engines (extensible)
  
• Service Units
  

• Service Assemblies
  

WSDLs

• JBI operates internally on the abstract WSDL
• Our binding components use the information from the concrete WSDL to communicate externally
• JBI is internally based on WSDL 2.0. So for example to normalize WSDL 1.1 defined messages, it defines a wrapped format