Binding Components are JBI components that enable pluggable external connectivity. In the JBI environment, they provide protocol independence for transport or communication, and can access remote services from within the JBI framework. In this way, they serve to isolate the JBI environment from the particular protocol by providing normalization and denormalization from and to the protocol-specific format, allowing the JBI environment to deal only with normalized messages.
Binding Components are custom built for each external protocol and are plugged in to the JBI meta container. This architecture allows any JBI component to communicate over any protocol or transport, such as SOAP, JMS, and so on. There is no need to implement these protocols in the business logic since loose coupling ensures quick assembly of different business solutions from different combinations of business services from a variety of systems. This flexibility gives third-party vendor product lines the ability to offer unique SOA services.
During a normal JBI transaction, the Binding Component consumes protocol-specific message data, converts it into a JBI-specified "normalized message" and hands it off to the Normalized Message Router (NMR) for consumption by any Service Engine. This effectively isolates the JBI environment from the particular protocol, allowing the JBI environment to deal only with normalized messages. On the opposite end, the Binding Component picks up the normalized message received from the NMR, "denormalizes" the message into a protocol-specific message, and sends it back to the consuming client.
JBI components, once installed in the JBI environment, interact with each other using message exchange documents published by the JBI component providing the services. These documents fully describe the message exchange using WSDL. These service descriptions are the sole source of information needed for service consumer components to interact with the service provider. The JBI environment provides a lightweight messaging infrastructure for the exchange of messages between the JBI components, which always use this messaging infrastructure as an intermediary.
Components that supply or consume services locally (within the JBI environment) are termed Service Engines. They enable services such as business logic, processing, transformation, and routing services. The service engines supported by Application Server are:
BPEL Service Engine | is a JBI engine component that provides services for executing business processes. It supports request/reply, asynchronous one-way invocations, and direct invocation between two business processes, and can monitor endpoint status. |
XSLT Service Engine | is a Java based transformation engine that is used to convert XML documents from one data format to another. It makes it easier for users to configure and expose XSL stylesheets as web services. |
Java EE Service Engine | functions as a service provider by enabling an endpoint in NMR. When a Java EE web service is deployed, the deployment runtime of Application Server notifies the Java EE Service Engine so that an endpoint is enabled in the NMR of the JBI runtime. The notification enables any component deployed in NMR to access the Java EE web service. |
Broken Link (Target ID: MANAGECOMPTARGETS)
Broken Link (Target ID: SHOWCOMPMETADATA)