Java Reference
In-Depth Information
To accomplish this goal, the JBI architecture defines four primary elements: service engines,
binding components, normalized message router, and the runtime environment. These are
shown in
Figure 14-2
.
Figure14-2.The JBI high-level architecture, as shown in the JBI 1.0 specification
Service engines
Service engines (SEs) are JBI components that enable pluggable business logic. An SE is a
standard container for hosting WSDL-defined service providers as well as service consumers
used internally by JBI. For example, the OpenESB project, which implements JBI, offers a
BPEL SE. You install the BPEL SE into OpenESB and then you can write a BPEL orches-
tration; create a JBI Service Unit project that contains XML descriptors (such as jbi.xml), the
BPEL XML file, the WSDL, and the XML schemas; bundle this into a .zipfile; and deploy it
to the JBI container. Once that's done, your BPEL SE is installed and you are able to accept
requests bound to a WSDL that ultimately will be routed to the BPEL engine, and execute the
.bpelfile inside that SE.
The JBI runtime hosts SEs, which in turn host service units to provide business logic, process-
ing, and transformation. There are a number of SEs available for download that you can plug
into your JBI-compliant bus. These include SEs for XSLT, scheduling, SQL, and Camel.
Binding components
Binding components (BCs) offer protocol independence, which represents the power of
JBI to help SOA-enable your enterprise. They provide transport protocols (and other
communication-based protocols such as those for talking to flat files) for external services to
use. They act as a proxy for services deployed in the JBI runtime that require a particular pro-
tocol.
