| The Java Business Integration (JBI) initiative (a.k.a. JSR-208) is an effort within the JCP to define a specification describing the way integration components, such as ESB services, can be plugged together in a vendor-neutral and portable fashion. Members of the JBI Expert Group (EG) include BEA, Borland, CGE&Y, Collaxa, IBM, IOPSIS, Intalio, Nokia, Novell, Oak Grove Systems, Oracle, RIM, SAP, SeeBeyond, Sonic Software, Sun Microsystems, Sybase, TIBCO, Tmax, Vignette, and WebMethods. JBI is considered an "enterprise" capability. However, the goal of the JBI EG is to not require the entire J2EE application server stack. JBI is primarily geared toward allowing vendors, whether application server based or not, to be able to plug together integration-enabling components in a portable and interoperable fashion. While JBI does not preclude the use of a J2EE server, a primary goal of JBI is to allow for a much broader adoption beyond the handful of J2EE application server vendors. The objective is to foster an ecosystem where any vendor with something to offer in the way of integration components and infrastructure may provide a JBI-compliant infrastructure, or plug their wares into one. Figure 10-1 shows the high-level view of what JBI defines. The JBI model consists of a JBI container, which houses JBI Service Engines (SEs), which in turn hold services. Figure 10-1. A JBI container houses SEs and services 
A JBI container provides protocol independence through the use of a Binding Component (BC) and a Normalized Message Service (NMS). The binding component is responsible for interfacing with an external protocol. Binding components are custom-built for each protocol and are pluggable into the JBI container. This allows any JBI component to communicate over any protocol or transport (SOAP, JMS, EDI, etc.) simply by plugging in the appropriate binding component. The responsibility of the binding component is to consume and produce the protocol-specific message data and hand it off to the NMS to be "normalized" for consumption by the SE. The NMS provides a common Service Provider Interface (SPI) for all services and SEs to write to. The NMS does not attempt to define the format of the message payload. Instead it focuses on sending and receiving messages, and providing a means of transferring and propagating transactional context and security context between the protocol and the SE. A JBI container may house multiple SEs, as illustrated in Figure 10-2. In an intracontainer environment, SEs communicate using the NMS and go through a BC, which simply acts as a pass-through or reflector. No message normalization is required and no protocol conversion or serialization is to be performed because each side of the BC conversation deals with an already-normalized message. As illustrated in Figure 10-2, all SEs are described using WSDL. Figure 10-2. A JBI container houses multiple SEs 
10.1.1 JBI as an ESB Container JBI provides a means for integration services to be hosted in a managed environment that allows pluggable SEs from third-party vendors to interoperate with each other in a portable fashion. These SEs and their respective services can be anything that facilitates integration and process management. For example, an SE could be an XSLT-based transformation engine, a CBR service, or an orchestration engine based on WS-BPEL. These services could be provided by three different vendors, and still be able to work together in the same managed environment. The BCs may be provided by different vendors as well. For example, a JMS vendor could provide its own JMS BC for hooking into its messaging layer, and an ESB vendor could provide a JBI container, as illustrated in Figure 10-3. The same ESB vendor could also provide a BC for JMS, SOAP, FTP, and a variety of other transports. Figure 10-4 shows the JBI ESB container plugged into the ESB. Figure 10-3. An ESB container as a JBI container 
Figure 10-4. An ESB/JBI container plugged into an ESB 
The adoption of JBI will help to foster and accelerate an ecosystem around pluggable, interoperable integration components. This will allow further industry momentum to build around a model of third-party services that can easily plug into an ESB environment. 10.1.2 JBI and Other Java Specifications While JBI does not require a full J2EE stack, it does take advantage of as many of the components as possible. Individual specifications from the J2EE stack, such as Java Transaction API (JTA), JMS, JAAS for security, and JAXB for data binding between Java and XML, will be referenced within the JBI work. Another JSR that is relevant to JBI is JAX-RPC 2.0. Historically, JAX-RPC has focused on the client-server view interaction model within an SOA, where JBI focuses on how an integration component can be plugged into an integration framework as an event-driven service. The JAX-RPC 2.0 Expert Group is in the process of defining an asynchronous callback API in order to migrate the interaction model away from a purely client-server view toward more of an event-driven service model. The API is similar to work that began in the Apache Axis project in 2002. Because of the overlap between the team of people who did the proposal in Axis and the JAX-RPC Expert Group, those of us involved in the Axis project decided to defer the Axis work and wait for it to become standardized first through the JCP. The JBI and JAX-RPC groups have decided to codevelop a common specification for the areas that overlap between the two technologies, such as asynchronous invocations and invocation handlers for passing transaction context and security context through their respective frameworks. |
