SOA Integration Java Specs Due Midyear
After over 2 years of vendor discussion, Sonic's Dave Chappell says 2005 will finally see the adoption of JSR-208 (Java Business Integration), which will set the stage for a new wave of Java-based integratable components. See why Chappell says JBI will make it easier for Java/J2EE architects and developers will find it easier to implement cutting-edge SOA-driven solutions.
Vice President and Chief Technology Evangelist
After over 2 years of vendor discussion, 2005 will finally see the adoption of the long-standing Java Business Integration (JBI) initiative (a.k.a. JSR-208), setting the stage for a new wave of Java-based integratable components.
As a result, Java/J2EE architects and developers will find it easier to implement cutting-edge SOA-driven solutions, because JBI will eliminate the time, costs and complexities of interoperating (and integrating) container-based data and rules with outside resources.
The JBI spec will likely be released by mid-year, with JBI container and binding component support from vendors starting to appear by year end. Enterprise architects adopting ESB infrastructures today to build new SOA based integration infrastructure can look forward to the promise of choosing best of breed integration components from their favorite source.
This will lead to more choice in implementation, and provide better adoption and adherence to standards which will prevent from getting locked into any one particular integration infrastructure vendor.
4 Benefits of JBI to Architects, Developers
Putting JBI To Work
The JBI elements that the JCP (Java Community Process) will adopt this year will define a specification describing the way that integration components can be plugged together as services in an enterprise SOA.
And then, the JBI JSR attributes will ignite among vendors a wave of new JBI-enabled services and components that will begin to articulate the "loosely-coupled" approach to application development and integration.
JBI services may include WS-BPEL engines, XSLT transformers, routing engines, dispatchers and other integration features which can be separated out as separate services. All of theses, and others we may not have thought of yet, will offer powerful interop/integration capabilities natively, because they will all exercise protocol independence and use common interfaces.
In specific, WSDL will describe the interfaces of JBI service components, and the XML data model will describe normalized messages that get passed between services.
The whole JBI movement, in fact, sets the stage for third-party vendors to offer off-the-shelf, interoperable, integratable components that can plug together to give Java/J2EE architects and developers a variety of easy-to-assemble event-driven (SOA-based) services using JBI's Service Provider Interface (SPI).
What About JBI and ESBs?
JBI will standardize key aspects of the ESB service container, and in combination with other efforts will help create a standardized architecture for Java-based ESBs. This will help solidify the definition of ESB products, much like the way that EJB drove the standard definition of an application server in the late 90s, and will assist with market adoption of ESBs.
The core architecture of JBI includes a container model for hosting integration components as event-driven services in an SOA. These JBI containers can then be linked together with each other in a protocol independent fashion to form an SOA based integration environment.
A key component of the JBI core architecture is the notion of a binding component that implements a protocol binding.
As illustrated in Figure 1, JBI defines a normalized message interface for passing messages between protocol bindings and the service implementations that are hosted in the JBI environment. JBI also defines a common means of providing configuration data, deployment details, and management interfaces for Java components that are plugged into the JBI container using the Java Management eXtensions (JMX) interface. Binding components will be provided by vendors, and will be able to interoperate with JBI compliant service engines through a Normalized Message interface.
Figure 1: JBI specifies a container model which includes protocol binding components.
Intermediary Integration Components
Implementing a business process definition that integrates two endpoints usually also involves additional processing, or mediation logic that helps facilitate the integration itself, such as data transformation and content based routing.
In an SOA based integration, this mediation logic can be made available as shared services in an SOA processing pipeline. In a JBI environment, a data transformation engine or a rules engine that performs routing of messages based on message content, can each be packaged up within a JBI container, and immediately exposed as a reusable integration service in an enterprise SOA.
JBI and WS-BPEL
JBI and WS-BPEL are highly complementary in that JBI can provide a container model to act as the hosting environment for an orchestration engine, as well as the intermediary integration components that the orchestration engine will be coordinating the interaction with. This orchestration engine can support WS-BPEL, ebXML BPSS, or other means of managing stateful process execution.
As illustrated in Figure 2, an orchestration engine that is hosted inside of a JBI container environment can take advantage of a common set of predefined protocol bindings to coordinate the interaction with external partner collaborations and with internal process components that are exposed as services, whether they are housed as JBI components or simply exposed through web service interfaces.
Figure 2: Orchestration engine coordinates other service interactions through JBI
An ESB is the piece of this infrastructure puzzle that really ties all of this together. As illustrated in Figure 3, an ESB will provide the common backbone for reliable message routing, service abstraction, common security model, distributed service configuration and management environment, and a plethora of protocol bindings.
Figure 3: JBI Compliant ESB Containers orchestrated by ESB using Orchestrated process definitions
ESB and SOA Summary
Adopting an ESB today will provide the substrate for a highly distributed and consistently managed event-driven SOA for integrating application assets across the extended enterprise. Looking forward, enterprise architects can look to ESBs to provide an environment for best-of-breed JBI compliant processing engines to flourish in.
Dave Chappell has over 20 years of experience in the software industry covering a broad range of roles including R&D, code-slinger, sales, support and marketing. He has a strong passion for shaping the future of technology, and enjoys sharing his knowledge and experience with others. Dave is well known for his writings and public lectures on the subjects of the Enterprise Service Bus (ESB), Message Oriented Middleware (MOM), enterprise integration, and evolving standards for Web services. As Director of Engineering for Sonic Software, Chappell led the development effort for SonicMQ, which has grown to become synonymous with enterprise messaging and the Java Message Service (JMS).