This article is sponsored by the Java Community Process.
System integration allows systems that were not initially designed to work together to act as one, unified system in support of a common business process. While much of the software industry has been moving from proprietary to open standards-based technologies, system integration has been a lone holdout: most tools and products supporting system integration are still based on vendor-specific integration techniques. The Java Business Integration API (JBI)  aims to challenge that status quo. JBI defines container services that enable system integration via Web service technologies and XML message exchanges.
JBI recently passed Final Specification stage in the JCP as JSR 208. In this article, Artima's Frank Sommers speaks with Ron Ten-Hove, co-spec lead for JSR 208. Ten-Hove is a senior staff engineer at Sun, where his group is responsible for that company's integration server products. In this interview, he gives an overview of JBI, contrasts JBI with traditional system integration approaches, and in general discusses how JBI will impact enterprise Java developers.
Frank Sommers: There was a lot of talk about JBI at the 2005 JavaOne Developers Conference. Could you give us a thirty-thousand-foot overview of JBI? How will JBI impact me, as a Java developer?
Ron Ten-Hove: JBI defines a container standard that allows plugging in other components, some of which may be containers themselves—for example, EJB containers. You can think of JBI as a container of containers. The JBI specs spell out how these components interoperate inside this larger container. Plug-in components inside a JBI container communicate in a service-oriented way, via message exchanges based closely on WSDL 2.0.
JBI affects different types of Java developers in different ways. For application developers, JBI brings two significant changes to the development process. First, JBI allows a developer to compose a new application platform by hooking together various existing JBI components. That means that a developer can assemble a run-time environment with only the functionality needed up front, and to easily extend that environment later, as requirements change. JBI provides that capability without vendor lock-in, freeing a developer from the headache of being married to one application server suite or integration server vendor.
In addition, the adoption of a JBI-based system integration style will encourage developers to adopt a service-oriented approach to creating applications. That means creating or packaging business functions as services, and defining an application by composing those services. Such a service-oriented development style will present new architectural and design challenges for developers, but those challenges are the result of the service-oriented approach, and are not unique to JBI.
Component and container developers will also benefit from JBI, because JBI allows these developers to concentrate on what they do best and where they add the most value. In the past, every integration or application technology vendor was forced to build—or buy—a lot of surrounding infrastructure pieces in order to bring to market a viable application or integration solution. With JBI, that is no longer necessary.
For example, a vendor may specialize in a type of business process automation. In the past, that vendor would have had to build transformation technologies and communications protocol support into its product. JBI, on the other hand, allows component developers to concentrate on their core specialty. With JBI, that vendor can depend on transformation service engines and binding components supplied by other vendors, to provide transformation and protocol support. Indeed, JBI components will support far more types of communications protocols and document transformation technologies than most vendors could support by themselves.
Frank Sommers: The JBI specs promise to make system integration easier by utilizing a declarative model. Could you explain how that contrasts with more traditional system integration approaches?
Ron Ten-Hove: Service-based integration works by modeling integrated applications as services. A WSDL declaration of a service provides all the information about that service to the service's consumers, such as the list of available operations, message formats, and so forth. Limiting a client's knowledge of a service to that service's WSDL definition was a very deliberate choice in JBI's design.
First, a WSDL interface minimizes the coupling between the service and its consumer. That, in turn, maximizes flexibility and reuse. Also, the WSDL provides a simple, well-defined, and well-understood basis for message exchanges between components, even if those components are provided by separate parties. That is key to assuring interoperation in a system composed of many third-party components. Finally, WSDL service definitions inside the JBI container allow an intermediated style of message exchange. That allows a JBI implementation to provide functions and features in addition to the services themselves.
Many existing integration approaches introduce far greater coupling between integrated applications. That becomes all too apparent when small changes in one application force simultaneous changes in others. That factor alone is driving many integration middleware vendors to adopt a service-oriented approach to integration.
No other integration approach allows for an open, standards-based set of plug-in components to be the primary means of architecting an integration solution. Any JBI-compliant integration solution will conform to the JBI specs, and will use WSDL's well-understood declarative style in connecting pre-existing applications.
That may bring an end to integration middleware vendor lock-in: changing application server or integration middleware vendors will no longer mean abandoning your investment in a component's integration technology. In addition, JBI's open, standards-based approach to system integration will likely lead to a wider choice of integration technologies, as you won't be restricted to a single vendor's integration product catalogue.
There will likely emerge a greater market for specialized component vendors supporting more obscure applications, or creating new, innovative technologies. That's because integration vendors won't need to create the full infrastructure needed to construct an integration solution, but can rely instead on JBI implementations and other components to provide that full solution. That type of market opportunity simply doesn't exist with traditional integration approaches.
We also anticipate that JBI will mean a boon to third-party integration tool vendors as well. The JBI standard defines packaging for the artifacts that define new services, applications that consume services, or both. For example, a single JBI service assembly can contain the artifacts needed to configure a BPEL engine, a binding component, and a transformation service engine to provide a complete integration solution. That standard packaging mechanism, along with standardized JMX management functions in the JBI environment, allows the creation of third party tools for composing and recomposing such service assemblies. Such tools will supplement JBI run-time and design-time environments.
This article is sponsored by the Java Community Process.