This article is sponsored by the Java Community Process.

Put your Integration on Auto-Pilot with JSR 208

---

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) [1] 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.

What is JBI?

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.

JBI versus traditional system integration approaches

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.

Service-based integration with JBI

Frank Sommers: Suppose I'd like to integrate three existing service components with JBI: an online shopping catalogue allowing the ordering of goods; a shipping service, such as UPS or Fedex, and an online payment system that facilitates credit card transactions. How could I integrate these three services with JBI, building an online store, for instance?

Ron Ten-Hove: First, you must find an appropriate technology to integrate these services. For instance, your shopping cart or shipping service might be available as WSDL-defined Web services that communicate via SOAP. Without JBI, you would effectively be locked into the integration technologies supported by a middleware vendor. By contrast, JBI allows you to obtain components providing integration technologies independent of the JBI implementation vendor.

If your example services are all available via WSDL-described service providers, then you need to be able to communicate with those services via the protocol bindings defined in those WSDL documents. Thus, the integration technology you need is the protocol bindings for those services. If that happens to be all Basic Profile 1.1 SOAP, then your job is even easier, because all JBI implementations must provide such a binding component. That requirement means that all JBI implementations can provide and consume services using SOAP as the transport protocol. Indeed, providing WSDL is the simplest way for external service providers to make themselves available to JBI environments. At the same time, JBI is very flexible about matching service provider technology to integration technologies to maximize the types of applications that can be integrated.

Assuming the use of SOAP, you make your three services available within the JBI environment by deploying their WSDL documents—the documents that describe the services to the binding component. These WSDL documents, in turn, make the services available for consumption by any other JBI component. For example, a BPEL4WS 1.1 service engine could be used to execute business processes, orchestrating the use of the catalogue, shipping, and payment services to create an order placement and fulfillment process. Incidentally, that new fulfillment process becomes a JBI service itself. Since the services are decoupled from the business process, they can be used flexibly in many different process types, and existing process types can easily adapt to changes.

But the protocol used by one or more of the services in your example may not be SOAP. In that case, you will need to find and install a binding component that supports the needed protocol. Of course, such a component may already be installed in your JBI implementation. Some protocols will require additional configuration information beyond what is supplied by the WSDL, and you will need to provide those configuration settings as well. After the binding component is installed and configured, the procedure is the same as for SOAP-based service components. JBI's multi-protocol capability allows service engines to take advantage of different transports in a neutral fashion. JBI even offers built-in protocol-hopping capability, allowing a service to receive a message via one protocol, and send a message via another.

This sort of service-based integration has many advantages. Reuse of integrated services promotes flexibility, and decoupling service consumers and providers allows changes to be made to a running system incrementally, with predictable effects. Services can be offered and consumed using many different transports. And switching transports is a matter of configuration, without affecting the service engine consuming or providing a service.

Integrating disparate applications

Frank Sommers: What kinds of services can be integrated with the JBI infrastructure? The JBI specs define services as WSDL-defined Web services, but I can also imagine this technology being used for integrating disparate internal systems, as long as such systems can be described via WSDL documents.

Ron Ten-Hove: Your reading of the specification is accurate. The ability of JBI to integrate disparate applications as WSDL-described services is only limited by the expressive power of WSDL itself, and the ability of the component author to map the application to such a model.

That requirement limits us to integrating applications with which interaction can be described with exchanges of structured messages. That sort of message-based integration has been used for years, and is a well-understood approach to integration practitioners. Gregor Hohpe's web site [2] contains a lot of information on current message-based integration patterns. Given the prevalence of message-based integration techniques in use today, it is safe to say that most applications can be integrated using this approach.

Frank Sommers: In addition to WSDL, what other agreements between services are necessary for JBI-style integration?

Ron Ten-Hove: JBI service consumers and providers need only agree on the abstract service definition, the WSDL portType, published within the JBI environment by the service provider. That service definition includes message type information. JBI provides additional mechanisms to allow other message formats not describable in WSDL to be used as well.

Message transformation

Frank Sommers: A key system integration task is to transform the input/output objects, or message formats, of one system to formats understood by another system. An online catalogue might specify a message in a format specific to that catalogue, whereas an online shipping service might require an input in a format that makes sense for that shipper's business.

Ron Ten-Hove: Message transformation has become a sub-industry in the integration world, especially where EDI [Electronic Data Interchange] and XML messages are used. The model of service provider-declared message formats makes it the responsibility of the consumer to ensure that a suitable message format is used in service requests. JBI provides message transformation by specialized service engines that offer the message transformation services. These services, again, are described in WSDL that the consumer can use to ensure that the correct message format is used. Allowing users to obtain the appropriate transformation technologies allows a JBI user to address her message transformation needs independently of business logic and application integration needs.

JBI use cases

Frank Sommers: A component looking to integrate with other components would query the JBI environment for the availability of services registered with that specific JBI instance. Prior to learning about JBI, I always imagined that such service discovery would take place with Web service registries, e.g., ebXML and even UDDI. An example here would be a developer of a "cool" and "can't-live-without" Web service. How can that developer, be it Amazon.com or Google, encourage others to use that service in the JBI context? What are the steps from publishing that service in some global directory to having others actually use that service inside their JBI environments?

Ron Ten-Hove: There are two distinct use cases for service discovery in JBI: Discovery of services offered within the JBI environment, and discovery of services external to the JBI environment. In the first instance, JBI components acting as service providers must provide WSDL service descriptions. Other JBI components, acting as service consumers, can query those descriptions. With external services, components can use external registries to discover external service providers, and integrate those services into the JBI environment.

JBI concentrates on business use cases, particularly those related to integration. Such use cases normally employ discovery of a particular service or service type at design-time. For that "must have" external Web service, the simplest approach may be to find the WSDL describing the service at design-time, and deploy that WSDL to a SOAP binding component in a JBI implementation. That will enable access to that Web service to all consumer components in the JBI environment. How that Web service WSDL is discovered is typically defined by design-time tools, such as a Web service registry browser integrated into an IDE. More sophisticated components can use run-time service discovery as well.

Frank Sommers: Instead of a JBI environment running at a business that wants to integrate with other businesses, could a JBI implementation be offered for the purpose of a "do-it-yourself" integration environment, where users could register their own services either for offering or consuming services? Do you see a Web-accessible JBI implementation being offered as a service?

Ron Ten-Hove: That model is certainly possible, although the presence of JBI would likely be hidden from the user of such a do-it-yourself integration environment. For example, a JBI service engine that functions as a BPEL service container could be used to host and execute a variety of business process types. Users could deploy new process definitions and describe new services to the BPEL service engine, without having to deal with the full JBI environment. Such services could be made available through a SOAP binding component, or other binding types, automatically, using JBI's dynamic service discovery mechanisms.

A true service-provider model would likely involve a more elaborate container component than this example BPEL process engine, but the principle remains the same: users can deploy to a container component, and depend on the underlying JBI infrastructure to make new services available through Web, or any other, protocols.

JBI is a standard defining an infrastructure for creating service-oriented architectures. Such a service provider model is an example of how JBI can be used. There are many other usage models, given the applicability of SOA to a wide variety of

Resources

[1] Java Business Integration, JSR 208:
http://www.jcp.org/en/jsr/detail?id=208

[2] Gregor Hohpe's Enterprise Integration Patterns site:
http://www.enterpriseintegrationpatterns.com/

[See also]

Ron Ten-Hove's weblog:
http://blogs.sun.com/roller/page/rtenhove

Standardizing business integration with JBI, an interview with Ron Ten-Hove by Nitin Barti:
http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1061937,00.html

Talk back!

Have an opinion? Readers have already posted 6 comments about this article. Why not add yours?

About the author

Frank Sommers is an editor with Artima Developer. He is also founder and president of Autospaces, Inc., a company providing collaboration and workflow tools in the financial services industry.