This week I spent some time looking into the recently approved and industry supported Java Business Integration specification, JSR-208.
The Java in the JBI refers to the integration software’s
runtime. It runs in a JVM. The JBI is not part of the J2EE specification. This
point is important for enterprises to understand for two reasons. First, your
J2EE application servers will not come with JBI containers inside. Second, the
use of JBI integration solutions is not limited to pure J2EE shops. JBI solutions
will provide integration between Java, .Net, legacy and application package
services. The Java implementation is essentially a black box, hidden from the
developers and integrators using the integration software.
While JBI is a vendor specification, the establishment (and
acceptance) of standards for integration infrastructure is an important (and
long overdue) milestone for the enterprise. It’s akin to the ratification of
the first J2EE specification that resulted in standardized application
infrastructure containers.
Beyond the pure existence of the standard, the service-oriented architecture of the JBI will resonate with both infrastructure providers (large, small, commercial,OSS) and enterprise IT professionals, each of whom are increasingly focused on interoperability, partnerships/collaboration, and choice.
The Basic JBI
Architecture
At the highest level, the JBI architecture centers on two
concepts: pluggable components and normalized message mediation.
Pluggable Components. The JBI authors recognize
that enterprises have unique integration scenarios, but as you break down those
scenarios into integration services, resource types, and connection protocols,
there are commonalities. For instance, many integration scenarios involve
protocol and data translation, and routing. However, the types of protocols,
and the data formats to be translated (both source and target) vary greatly. Of
course, data translation is just one type of integration service; others are
business process execution, service orchestration,
authentication/authorization, data validation, event publication and
subscription, etc.
The JBI model, then, needed a way to support a (seemingly) infinite list of protocols, and integration services. The JBI solution, and cornerstone of the JBI architecture, is pluggable components. The JBI provides for a plug-in framework that accepts software components from a variety of providers as long as the components are JBI compliant.
There are two types of JBI components:
- Service Engines (SE): The service engines provide the actual
integration services, such as data translation using XSLT. In that case, the service
engine hosts an XSLT engine, and contains artifacts (style sheets) for
particular data translations. Adhering to SOA, the integration services may be
service providers or service consumers. Since almost anything could be a
service engine, including a Business Process Execution Language (BPEL)
engine or J
2EE container, the JBI is often referred to as “a container of containers.” Given the container nature of the service engines, you may deploy business services, such as a process-oriented service, into a target container in the JBI.
- Binding Components (BC): The binding components convert protocol and transport specific bound messages to a normalized XML message format (and vice versa). The service engines communicate using the normalized message format. The JBI specification requires a WS-I binding component, but since binding components are “pluggable,” you can install JBI-compliant BCs for whatever protocols and APIs are present in your environment.
JBI Mediator. The
binding components and service engines do not interact directly. Following
solid architectural constructs, there is a mediator,
which handles interactions between binding components and service engines, and
between service engines. This mediator is the normalized message router. The
normalized message router accepts normalized XML messages from the binding
components (dropped into delivery channels), and invokes service engines with
WSDL-based messaging. The mediator also has an outbound role, picking up
messages from a service engine’s delivery channel and dropping them into the
delivery channel of a binding component.
Why JBI is Good for
the Enterprise
For the enterprise, the JBI, and the advent of service-oriented
integration solutions, is as the saying goes, “all good.” Of course, this is
only release 1.0 of the JBI, and like any specification, some areas still need
fleshing out, such as best practices for in-JBI service deployment and collaboration,
and specifications for distributed JBI.
However, even at this early stage, the advantages for the enterprise
include:
- First, the obvious. Standards bring choice. Enterprises won’t be locked in to a particular vendor or product suite.
Opportunity to reuse integration services, across integration scenarios, and over time, possibly application solutions. If application software vendors adopt JBI infrastructure (SAP AG and Oracle participated in the expert group), enterprises can standardize on one rules service, one BPEL engine, one workflow engine, and so on. No longer will enterprises have to deal with the added complexity of “infrastructure inside” application packages. Using JBI, enterprises would be able to install their chosen service engine in the application vendor’s software stack.
Of course, as with any technology, you need to do your own exploration, and make informed choices for your business. But, if you are pursuing a service-oriented architecture strategy and/or are tackling integration initiatives, you might want to start “playing” with some of the JBI OSS and reference implementations.
Comments