JBI Runtime

The Java Business Integration runtime
(JBI runtime) provides a distributed infrastructure used for enterprise
integration. It consists of a set of binding components and service
engines, which integrate various types of information technology assets.
The binding components and service engines are interconnected with
a normalized message router. Binding components and service engines
adapt information technology assets to a standard services model,
based on XML message exchange using standardized message exchange
patterns. The JBI runtime provides services for transforming and routing
messages, as well as the ability to centrally administer the distributed
system.

This JBI runtime incorporates the JSR 208 specification
for JBI and other open standards. The JBI runtime allows you to integrate
web services and enterprise applications as loosely coupled composite
applications within a Service-Oriented Architecture (SOA).

Additional components, tools, and documentation are available
for download. Refer to Project Open ESB for more information
on the additional components, tools, and documentation that are available.

The Java EE Service Engine
acts as a bridge between the Java EE and JBI runtime environments for web
service providers and web service consumers. The Java EE Service Engine
provides better performance than a SOAP over HTTP binding component due
to in-process communication between components and additional protocols provided by JBI binding
components such as JMS, SMTP, and File.

The JSR 208 specification allows transactions
to be propagated to other components using a message exchange property
specified in the JTA_TRANSACTION_PROPERTY_NAME field.
The Java EE Service Engine uses this property to set and get a transaction
object from the JBI message exchange. It then uses the transaction
object to take part in a transaction. This means a Java EE application
or module can take part in a transaction started by a JBI application.
Conversely, a JBI application can take part in a transaction started
by a Java EE application or module.

Similarly, the JSR
208 specification allows a security subject to be propagated as a
message exchange property named javax.jbi.security.subject.
Thus a security subject can be propagated from a Java EE application
or module to a JBI application or the reverse.

To deploy a Java EE application or module as a JBI service
unit, use the Admin Console or the asadmin deploy-jbi-service-assembly command. For more information about the asadmin
deploy-jbi-service-assembly command, see the Sun Java System Application Server 9.1 Reference Manual.

Using the jbi.xml File

Section 6.3.1 of the JSR 208 specification describes the jbi.xml file. This is a deployment descriptor, located in the META-INF directory. To deploy a Java EE application or module
as a JBI service unit, you need only specify a small subset of elements
in the jbi.xml file. Here is an example provider:

The Java EE Service Engine enables the endpoints described in
the provides section of the jbi.xml file
in the JBI runtime. Similarly, the Java EE Service Engine routes invocations
of the endpoints described in the consumes section
from the Java EE web service consumer to the JBI runtime.

Using Application Server Descriptors

To determine whether a web service endpoint is enabled
in the JBI runtime environment, you can set a jbi-enabled attribute
in the Application Server. This attribute is set to false (disabled) by default.
To enable
an endpoint for JBI, set the attribute to true using
the asadmin set command. For example, if an endpoint
is bundled as a WAR file named my-ws.war with an
endpoint named simple, use the following command:

Determining whether requests from a web service consumer are routed
through the Java EE Service Engine is unnecessary and deprecated, but supported for
backward compatibility. You can set a stub-property named jbi-enabled in the consumer's sun-web.xml or sun-ejb-jar.xml file. This property is set to true (enabled) by default.
Here is an example of the sun-web.xml file: