QUESTION & ANSWER

Standardizing business integration with JBI

By Nitin Bharti 24 Feb 2005 | SearchWebServices.com

Digg This!     StumbleUpon     Del.icio.us

Can you talk a bit about your role at Sun Microsystems your involvement with the JBI Java Specification Request (JSR) 208?
Ron Ten-Hove: I'm a senior staff engineer at Sun, working in the Java Web Services, integration products group. My group is responsible for Sun's integration server products (for EAI and B2B). I'm also one of Sun's representatives on the OASIS WS-BPEL [Web services Business Process Execution Language] technical committee.

I was involved with JSR 208 before it was even submitted to the Java Community Process. I was initially Sun's member of the expert group, when it was formed in mid-2003. I became co-spec lead of the JSR eight months ago, along with Peter Walker [also of Sun].

Ron Ten-Hove

What is the JBI specification?
Ten-Hove: The JBI specification is a standard for what can be called a "container of containers." It describes the architecture and behavior of a framework that hosts plug-in components, and allows them to interact using a WSDL [Web Services Description Language] 2.0-based messaging system, using WSDL's services model. The goal is to allow users to obtain plug-in components that provide all the functions needed to provide an integration solution, without getting locked into a particular vendor. Components will be portable between JBI implementations.

The plug-in components can be almost anything. A few examples are: EJB [Enterprise JavaBeans] containers, BPEL4WS [Business Process Execution Language for Web Services] business process engines, XSLT [Extensible Stylesheet Language Transformation] transformation engines, SOAP protocol adapters and EDI [electronic data interchange] protocol adapters. The JBI specification seeks to not impose limits on what components can do, but instead defines a crisp, service-oriented view of all components, allowing them to interact without regard to the underlying implementation. For example, a BPEL4WS business process engine component can use a wide variety of communications protocols, without having specific knowledge of any of them.

Where does JBI fit in to the spectrum of other business integration specifications?
Ten-Hove: JBI is, by design, very well aligned with the major Web services specifications, especially BPEL4WS. The JBI messaging model is based on WSDL, as is BPEL. A BPEL engine fits very naturally into a JBI environment, with other components providing things like SOAP bindings, and the JBI host itself the connective "plumbing" to allow the BPEL engine to use SOAP in a loosely coupled fashion.

Can you provide a scenario of how Java 2 Enterprise Edition developers will leverage JBI in real-world applications?
Ten-Hove: J2EE developers can use JBI to access a wide variety of integrated services, and expose existing J2EE components as services as needed.

This creates many possibilities. For example, EJBs can be "composed" into stateful business processes, using process languages like BPEL. This helps the J2EE developer by allowing him to write business processes using BPEL, rather than embedding the process logic into Java code.

The benefits to J2EE developers [and Java developers in general] are really a function of the services provided by the plug-in components. A document transformation engine will give the J2EE developer access to its services. A communications protocol adaptor component will give the J2EE developer access to that protocol.

More importantly, the J2EE developer can design his applications without specific knowledge of how such services are provided. The connections between service providers and consumers are made at run-time, not design-time.

Lastly, JBI provides the infrastructure and architectural underpinning for migrating to service-oriented architecture. By shifting from creating applications to creating and using services, JBI provides developers with a practical means of realizing the benefits of an SOA.

Can you describe the structure of what a typical JBI container would look like?
Ten-Hove: A typical example that I use consists of the following components:

• A BPEL4WS business process engine, which provides stateful business process management. BPEL is a good language for doing service orchestration: performing a set task by sequencing service invocations according to business logic.
• An XSLT transformation engine, which provides a set of XML-to-XML transformation services enabling schema changes. For example, there are several existing purchase order XML formats used in the industry, and it is often necessary to convert from one format to another.
• A WS-I Basic Profile 1.1 compliant binding component, providing SOAP communications in two directions: outbound, invoking external service providers, and inbound, where external clients invoke services that our example system provides.
• An AS2 (applicability statement 2, and IETF-defined EDI protocol) binding component, providing inbound and outbound EDI messaging.
• A JMS binding component.

How would components in a JBI container interact with one another? Can you describe a typical business use case?
Ten-Hove: The BPEL engine hosts many business process types, including a purchasing process that allows external customers to submit purchase orders, and receive resulting ship notices, invoices, etc. The process itself will contain "initiating activities" that, upon receiving a new purchase order, will create a new process instance. The PO is received by a means of a service offered by the BPEL engine. Of course, BPEL doesn't know (or care) about the protocol used to deliver the PO; it just cares about the XML received.

For more information Learn about the new features in J2SE 5.0   Will Web services eliminate the need for EAI?

In this example, purchase orders can be received by three separate means: SOAP, AS2, and JMS, each of which we have one binding component for. Customers can choose which protocol they wish to use. When a protocol component receives a request, it converts it to a normalized form (a normal representation of an XML message, conformant to abstract WSDL), plus message meta data such as security information, transaction identifiers, etc.) and passes it to JBI. JBI determines which component should supply the desired service, and passes the normalized message along to (in this case) the BPEL engine, which will create a new process instance as just mentioned.

If the process needs to transform the received PO to a canonical format, it invokes a transformation service. Again, JBI will determine which component provides the needed service, and route the request to our XSLT engine, and the response (the transformed PO) back to the BPEL engine.

The next step in the business process is to check the customer's credit worthiness. The BPEL engine constructs a normalized request, which JBI will route to a suitable service provider, in this case the SOAP binding component. This will form a SOAP request, and send it to the external credit agency we are using to do credit checks. The response is normalized by the SOAP binding component, and JBI returns the response to the BPEL engine.

The process continues with more steps for checking inventory, fulfilling the order, arranging shipping, sending ship notices and finally invoicing the customer. The main points are:

• The BPEL engine, as a consumer and provider of services, deals only with normalized (abstract) messages and abstract service names.
• JBI normally determines which component provides a service (although "smart" components can make this choice if they want to).
• Normalized messages are protocol-neutral.

What are some products/tools that will support this specification?
Ten-Hove: It is anticipated that software vendors that are members of the JSR 208 expert group will add JBI support to their current product offerings (such as application servers and integration suites), as well as offer a variety of components for use with JBI.

Design-time tooling is important, to configure components to perform their individual services and tasks. Components will obviously be provided with appropriate tooling.

When do you expect the JSR to be ratified and what version of J2EE will it ship in?
Ten-Hove: There is no current plan to incorporate JBI in J2EE 5.0. If JBI does become part of J2EE, it would have to be part of 6.0 or later.

Tags: Enterprise Application Integration (EAI),  Java Web Services,  JBI (Java Business Integration),  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Enterprise Application Integration (EAI) Enterprise mashups: Tools build data integrations ESB Tutorial ESB watered down by EAI, but distinction remains Second look at Oracle licenses in wake of Sun merger JNBridge releases JNBridgePRO 4.1 What are chief criteria for analyzing "enterprise mashups"? Especially in relation to a "mainframe wrappering" project? Crosscheck Networks acquires XML gateway maker Forum Systems Oracle buys Sun for $7.4B Enterprise architecture must focus on business value The business side has silos too Enterprise Application Integration (EAI) Research Java Web Services Java Web services programming challenges met with specialized framework Tools add Web services to existing Java EE applications Video: Author says Enterprise JavaBeans is here to stay Languages like F# may replace Java, says Ted Neward Mobile development growing in prominence according to survey OSGi framework helps you manage Java components SpringSource moves VMware up the stack SpringSource gains cloud console: Q&A with Cloud Foundry head Adopting OSGi requires patience and money, but development flexibility results Speed up application deployment with automated blackbox frameworks JBI (Java Business Integration) FUSE ESB brings Apache ServiceMix 4.0 to market Eclipse Ganymede: SOA project adds WS-Policy, SCA tools Sun Java CAPS chugs down SOA open source track Deutsche Post delivers .NET in Java CRM thanks to SOA Eclipse Swordfish SOA runtime mixes SCA, JBI and OSGi Swordfish may lure SMBs into SOA waters Java EE and JBI lessons SOA standards WS-Policy, SCA and SDO advancing rapidly Eclipse Europa, part 2: SOA tools ready for test drive Debate rages over SCA for SOA

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary webMethods  (SearchSOA.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary