Concepts: JBI Container and pre-JBI Java CAPS

JBI components can intercommunicate with pre-JBI Java CAPS components that are exposed as web services. The Java EE Service Engine contains all pre-JBI CAPS components and presents them to the JBI container as WSDL. JBI can thus make use of existing or new pre-JBI components that contain complex business logic and mappings, and the pre-JBI projects can call services provided by JBI components.

Figure 1–1 Intercommunication With JBI Mediated by Java EE Service Engine

For the purposes of this work, the term “pre-JBI” is used to encompass both repository-based components, such as OTDs, JCDs, and eWay adapters, as well as Java EE objects, such as JCA adapters and web service-based EJBs.

Figure 1–2 Categories of JBI Components and Pre-JBI Components

The JBI container can only use repository-based modules after they have been JBI-enabled. For example, a repository-based CAPS project is equipped with a “JBI hook” by adding a JBI Bridge component to a connectivity map and building a new deployment profile, creating a JBI-enabled enterprise archive (EAR) file. This EAR file is then used by the Java EE Service Engine to present WSDL to the NMR and thus to components in the JBI container.

If you have used pre-JBI technology to create EJBs or servlets, you can use the Java EE SE to expose their business logic as web services, defined in WSDL. Therefore, when they are plugged into the NMR, they intercommunicate transparently with other JBI components.

In the other direction, an existing pre-JBI CAPS project can easily be extended to use any functionality provided by JBI components, because all JBI components, by definition, are described by WSDLs that expose the web services they provide. In repository-based projects, you use the WSDL OTD to communicate with the WSDLs exposed by JBI components.