Java Business Integration (JBI) is a standard developed under the Java Community Process (JCP) as an approach to implementing a service-oriented architecture (SOA). It defines an environment for plug-in components that interact using a services model based directly on Web Services Description Language (WSDL) 2.0. The plug-in components function as service providers, or service consumers, or both.
Components that supply or consume services locally (within the JBI environment) are termed Service Engines. Components that provide or consume services using some sort of communications protocol are called Binding Components.
JBI components, once installed in the JBI environment, interact with each other using message exchange documents published by the JBI component providing the services. These documents fully describe the message exchange using WSDL. These service descriptions are the sole source of information needed for service consumer components to interact with the service provider.
The JBI environment provides a lightweight messaging infrastructure for the exchange of messages between the JBI components, which always use this messaging infrastructure as an intermediary.
Figure 1 below illustrates basic messaging concepts in a JBI runtime environment.
Figure 1: JBI Runtime Environment
Figure 1 shows JBI components (Service Engines and Binding Components) in a JBI runtime environment. Each JBI component communicates with the JBI messaging infrastructure using only the communication protocol it is expecting (for example, using HTTP SOAP, JMS, or some other communication protocol).
Because each JBI component communicates with the JBI messaging infrastructure, each component thus can communicate with any other JBI component within the JBI runtime environment. Note that Service Engines provide other JBI components access to services while Binding Component provide access to services that are external to the JBI environment.
Service Engines provide or consume services locally within the JBI runtime environment, enabling services such as business logic, processing, transformation, and routing services.
For example, some Service Engines might execute long-lived business processes, while others provide data transformation or sophisticated Electronic Data Interchange (EDI) services.
The following links describe in greater detail the Service Engines available by default with Open ESB Starter Kit:
Binding Components provide protocol independence for transport or communication. They access remote services using a specific protocol, and place those services into the JBI messaging infrastructure. Other JBI components can then access these services from the messaging infrastucture.
Binding Components are specialized for specific external protocols, such as SOAP, JMS, and others. This allows any JBI component to communicate over any protocol or transport available from Binding Components deployed to the JBI runtime environment. There is no need to implement these protocols separately in business logic.
The following links describe in greater detail the Binding Components available for Open ESB Starter Kit:
Figure 2 below illustrates the JBI runtime environment available with Open ESB Starter Kit. It includes the default JBI components as well as additional JBI components that can be separately installed and deployed into the JBI environment. Included in this figure are references to the JBI administrative functions necessary to install, deploy, and run JBI components.
Figure 2: JBI Runtime Environment (Plus Additional Components) for Open ESB Starter Kit
Each type of JBI component needs specific application artifacts to configure how the component provides and consumes services. For example, an EAR file can be used to configure an EJB Service Engine to provide a desired service.
A collection of such related artifacts is called a Service Assembly. For example, the EAR file mentioned above plus another application artifact, the SOAP Binding configuration data used to make the service available to SOAP clients, would constitute a service assembly. Service assemblies are typically created in a development tools environment, such as that provided by NetBeans 5.5 Enterprise Pack.
Once an assembly is ready for use, it is deployed to the JBI environment. The JBI environment automatically distributes the artifacts to the appropriate JBI components that use them.
You can deploy service assemblies using either the tooling available with the NetBeans 5.5 Enterprise Pack or the Ant tasks provided with Open ESB Starter Kit and executed using the Application Server 9.0 Update 1
Deploying Service Assemblies to Components
One of the most frequent JBI administration tasks is to deploy a service assembly to a component. Here is the typical order of events for this scenario:
Install a JBI component.
Start the component.
Installing a component does not automatically start the component. You must explicitly start the component after it is installed.
Deploy a service assembly to a component.
This task is performed multiple times, once for each service assembly you deploy to the component.
Make sure the component is in the started state before the service assembly is deployed to it.
Start the service assembly.
Once a service assembly is deployed, it must be explicitly started. You cannot exchange messages or invoke services within that service assembly unless the service assembly is in the started state.
(Uninstall a JBI component.)
When uninstalling a JBI component, first make sure all service assemblies are stopped, shut down, and undeployed. This is to avoid other services attempting to access services that will no longer be available because of the uninstallation.
Then stop, shut down, and uninstall the JBI component.