 |  |  |  |  |
| | | | |
 |  |
The JBI component framework provides a pluggable interface between the functional units installed into the JBI environment and the infrastructure services offered by the JBI environment. The framework divides JBI components into two types based on their functionality. The framework also defines a packaging mechanism for deploying functional units into JBI components.
JBI defines two types of components:
Service engines are components that provide some of the logic needed to provide services, like message transformation, orchestration, or advanced message routing, inside of the JBI environment. They can only communicate with other components inside of the JBI environment. Service engines act as containers for the functional units deployed into the FUSE ESB.
Binding components provide access to services outside the JBI environment via a particular protocol. They implement the logic needed to connect to a transport and consume the messages received over that transport. Binding components are also responsible for the normalization of messages as they enter the JBI environment.
The distinction between the two types of component is purely a matter of convention. The distinction makes the decoupling of business logic and integration logic more explicit.
JBI defines a common packaging model for all of the artifacts that can be deployed into the JBI environment. Each type of package is a ZIP archive
that includes a JBI descriptor in the file META-INF/jbi.xml. The packages differ based on root element of the JBI descriptor and
the contents of the package. The JBI environment uses four types of packaging to install and deploy functionality. The two most common types of packages
encountered by an application developer are:
Service assemblies are a collection of service units. The root element of the JBI descriptor is a service-assembly
element. The contents of the package is a collection of ZIP archives containing service units. The JBI descriptor specifies the target JBI component
for each of the bundled service units.
Service units are packages that contain functionality to be deployed into a JBI component. For example a service unit intended for a routing
service engine would contain the definition for one or more routes. Service units are packaged as a ZIP file. The root element of the JBI descriptor
is a service-unit element. The contents of the package are specific to the service engine for which the service unit
is intended.
![[Important]](imagesdb/important.gif) | Important |
|---|---|
Service units cannot be installed without being bundled into a service assembly. |
Once configured by one or more service units a JBI component implements the functionality described in the service unit. In doing so, the JBI component takes on one of the following roles:
Depending on the number and type of service units deployed into a JBI component, a single component can play one or both roles. For example, the HTTP binding component could host a service unit that acts as a proxy to consumers running outside of the FUSE ESB. In this instance the HTTP component is playing the role of a service provider because it is receiving requests from the external consumer and passing the responses back to the external consumer. If the service unit also configures the HTTP component to forward the requests to another process running inside of the JBI environment, the HTTP component also plays the role of a service consumer because it is making requests on another service unit.
| |  | |
 |
