This week I spent some time looking into the recently approved and industry supported Java Business Integration specification, JSR-208.
Beyond learning that the JBI/SOA session was the most attended session on Day 1 of JavaOne (listen to Tuesday 6/28 8:00-9:30), and that the blogosphere is generally unconcerned with IBM and BEA’s JBI abstentions (as am I), I learned that JBI offers some real advantages for the enterprise.
In this posting, I offer some excerpts (JBI basic architecture and enterprise advantages) from my PSGroup JBI report. For the full (currently free) report, go here.
Focus of the JBI. The JBI specification is a vendor specification directed at providers of integration software and SOA infrastructure. The specification articulates the architecture for building integration software that is actually a framework for pluggable, interactive, integration components. Essentially, the JBI outlines a service-oriented architectural blueprint for integration infrastructure.
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.
- The cost of enterprise integration technology will be more palatable, and manageable. After choosing a JBI environment, enterprises can add integration services and adapters in an a la carte fashion.
- The open source JBI offerings (ServiceMix ESB, Sun’s Java ESB, FiveSight’s BPEL engine) allow enterprises to freely experiment with the technology prior to making financial outlays or commitments.
- Service-oriented approach to enterprise integration technology.
- 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.
