JBI Component Overview

Java Business Integration (JBI) is an implementation of the JSR 208 specification, developed as a way to implement a service-oriented architecture (SOA). JBI defines an environment that offers plug-in components that function as service providers (providers of services), service consumers (consumers of services) or both, and interact using a services model based directly on Web Services Description Language (WSDL) 2.0.

Java CAPS utilizes four types of JBI (Java Business Integration) Components:

• Service Engines: Provide or consume services locally within the JBI runtime environment, and enable services such as business logic, processing, transformation, and routing services. For example, one Service Engine might execute long-lived business processes, while others provide data transformation or sophisticated Electronic Data Interchange (EDI) services.

• Binding Components: Provide protocol independence for transport or communication. They access remote services using a specific protocol, such as HTTP or SOAP, and place those services onto the JBI Normalized Message Router. The binding component converts messages from their specific protocol to XML, and from XML, back to their specified protocol, a process called normalizing and denormalizing. Normalizing a message allows other JBI components to access these messages from the NMR. Binding components are specialized for theirspecific external protocols, such as HTTP, 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.

  Binding components are specialized for their specific external protocols. 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.

• Shared Libraries: Provide Java classes that are available to more than one JBI Component. For example, the Sun WSDL Library can be shared by several different binding components.

• Service Assemblies: Provide specific application artifacts to configure how the component provides and consumes services. For example, an EAR file can be used to configure a Java EE Service Engine to provide a desired service. A collection of such related artifacts is called a Service Assembly. Each application artifact in the service assembly is a service unit. The service assembly contains configuration information that defines to which JBI component each service unit is deployed. 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, constitute service units within a service assembly. Once an assembly is ready for use, it is deployed to the JBI environment. The JBI environment automatically distributes the service units to the appropriate JBI components that use them. Service assemblies are typically created and deployed in a development tools environment, such as that provided by the NetBeans IDE.

  For example, the EAR file mentioned above plus another application artifact, the HTTP Binding configuration data used to make the service available to SOAP clients, constitute service units within a service assembly. Once an assembly is ready for use, it is deployed to the JBI environment. The JBI environment automatically distributes the service units to the appropriate JBI components that use them.

  For Java CAPS, service assemblies are typically created and deployed in a development tools environment, such as that provided by the NetBeans IDE. The following image displays the expanded NetBeans JBI Manager and the four types of JBI Components.