This article is sponsored by the Java Community Process.
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.
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  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.
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.
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 problems.
 Java Business Integration, JSR 208:
 Gregor Hohpe's Enterprise Integration Patterns site:
Ron Ten-Hove's weblog:
Standardizing business integration with JBI, an interview with
Ron Ten-Hove by Nitin Barti:
This article is sponsored by the Java Community Process.