THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Anchor
5. JBI
...
...
Overview
What is JBI ?
...
A brief introduction to JBI is available in the What is JBI? document. This document is more in-depth and supplemental.
...
JBI is a java based standard to build integrations systems by using plug-in components which interoperates through mediated normalized message exchanges.
The message exchange model is based on the web services description language (WSDL).
The figure at the top shows a high level concept of JBI of the plug-in framework. The JBI environment provides interfaces to be used by plug-in components, while the components provides interfaces used by the JBI environment. Components do not interact with each other directly. Instead, as shown in the bottom figure, JBI acts as an intermediary to route messages between components. This separation is the key to decoupling between service providers and consumers, which is one of the goal of service oriented architectures. In addition, it provides a key point for message processing and monitoring.
...
...
...
...
In this WSDL-based, service-oriented model, JBI plug-in components are responsible for providing and consuming services. By providing a service, a component is making available a function or functions that can be consumed by other components (or even itself). Such functions are modeled as WSDL 2.0 operations, which involve the exchange of one or more messages. A set of four WSDL-defined, basic message exchange patterns (MEPs) crisply defines the sequence of messages allowed during execution of an operation. This shared understanding, between consumer and provider components, of the message exchange pattern is the foundation of interoperability of such components in JBI.
The services provided by components (if any) are described to JBI by the component, using WSDL 1.1 or 2.0. This provides an abstract, technology-neutral model of services using XML-based message exchanges. WSDL also provides a mechanism for declaring additional service metadata of interest to service consumers and JBI itself. Components can query JBI for the for the WSDL describing available services.
JBI Architecture
...
...
This picture describes the architecture of the JBI system.
- The JBI environment provides deployment, control & monitoring features through JMX based administration tools
- The Normalized Message Router or NMR, which provides the mediated message exchange infrastructure
- Components (in white rectangles)
Components are divided in two categories:
- Service Engines (on top) provides business logic and transformation services and also consumes such services.
- Binding Components provide connectivity to services external to the JBI environment.
Service engines and binding components can function as service providers, consumers, or both. Note that the distinction between SEs and BCs is purely pragmatic, but the separation of business logic from communications logic reduces complexity and increases flexibility.
...
...
...
The JBI environment, in addition to the messaging system, defines a management structure based on JMX which provides standard mechanisms for:
...
The core message exchange concept implements WSDL messaging. Service requests are generated by consumer components, routed by the NMR, and delivered to a provider component. For example, the BPEL SE may generate a request, which happens to be provided by the external service provider connected to the WS-I BC. The NMR will route the request to the WS-I binding. The SE in this case is a service consumer, and the BC a provider.
WSDL messaging model
...
...
JBI models services produced and consumed by components using Web Service Description Language 1.1 or 2.0. When the terminology differs between the two version, the 2.0 one is used. This is mainly the case for the interface and endpoint terms, which are called respectively "port type" and "port" in WSDL 1.1.
WSDL provides a declarative model of message-based services on two levels:
- The abstract model defines services without references to a particular protocol or wire encoding
- The concrete model is bound to a particular communication protocol and communications endpoint
JBI uses the abstract service model as the main basis for component interactions. Components play one of two roles in such interactions:
- Service provider. The component that performs the given service (either directly or as a proxy for an external provider)
- Service consumer. The component that invokes a given service (either directly or as a proxy for an external consumer)
...
Abstract model
JBI models services produced and consumed by components using Web Service Description Language 1.1 or 2.0. When the terminology differs between the two version, the 2.0 one is used. This is mainly the case for the interface and endpoint terms, which are called respectively "port type" and "port" in WSDL 1.1.
...
The concrete service model defines the following items:
- Binding types. A binding type identifies the type of protocol to which the service is being "bound".
- Endpoints. An endpoint designates the communications endpoint information needed by a service consumer to interact with a service provider, using a particular protocol. In JBI endpoints are pro forma; the only protocol used internally is the standard Java-based JBI messaging contracts, which do not involve the use of normal communications protocols at all. An endpoint definition includes the following items that are of interest to JBI:
- Endpoint name. This is a simple name, used to designate the endpoint within its service.
- Binding type. This associates a binding type with an endpoint.
- Service. A service is a collection of endpoints that offer access to the same service. A service "implements" a particular service type (interface). A service has the following items:
- Service name. A qualified name used to indicate the particular service implementation.
- Service type name. The name of the interface implemented by the service.
- Endpoints. The service "contains" one or more endpoints, which are the individual endpoints providing access to the concrete service.
...
...
The Normalized Message Router (or NMR) receives message exchanges from JBI components and routes them to the appropriate component for processing. This decouples the service producers from consumers and enable additional processing.
Consumers and providers
...
providers
...
JBI components (Service Engines and Binding Components) can act as a service consumer, a service provider or both. The diagram to the right outlines this using the example of a ServiceMix HTTP Consumer BC and a ServiceMix HTTP Provider BC. Notice where requests are initiated and the direction of the arrows to denote the flow from the initiator.
The provider makes a WSDL-described service available through an endpoint. This service implements a WSDL interface, which is a collection of operations.
The consumer can invoke the service by creating a message exchange that invoke a particular operation.
Consumers and providers only share the abstract service definition and are thus decoupled, as the consumer does not know the protocol and location of the invoked service.
Several services can implement the same WSDL interface so a consumer looking providers of an interface may find more than one endpoint.
...
...
Normalized message
...
JBI uses the concept of a normalized message for interactions between consumers and providers.
A normalized message consists of three parts:
- A payload, which is an xml document that conforms to a WSDL message type without any protocol or encoding
- Properties (or metadata) holds extra data associated with the message (security, transactions ...)
- Attachments are arbitrary (non-xml) data that contain a data handler to manipulate them
...
...
Delivery Channel
...
...
JBI defines a standard packaging for installing new components and deploying artifacts onto these components that can function as "containers".
All these artifacts contain a JBI descriptor in the META-INF directory called jbi.xml.
...
...
- Components installers contain the libraries and resources needed to run the component. Components can references Shared Libraries.
- Shared Libraries are collection of jars that can be shared by several components
- Service Units are artifacts meant to be deploy deployed to a specific component. Aside from the JBI descriptor, the service unit packaging is specific to a component and can take various forms: a single XSLT style sheet, a BPEL process, or some java classes ...
- Service assemblies are collections of Service Units. Service units can not be deployed directly and must be packaged in a service assembly which contains the service units and associated metadata.
...
- JSR208: Java Business Integration
- JBI Components: Part 1 (Theory) by Ron Ten-Hove
- Using JBI for service oriented integration by Ron Ten-Hove
- JBI - A Standard-based approach for SOA by Meeraj Kinnumpurath
- Steve Vinoski's JBI article
- Frank Summer's SOA JBI
- JBI - the only game in town
- Carlos's blog post on JBI
- JBI gains Industry support EbizQ
- Sun's JBI site
- Carl-Henrik Wolf Lund created a (Norwegian) presentation on JBI
- SCA, JBI and more.. which echos our FAQ entry
- Java Business Integration (JBI) Gains Industry Support by Patricia Seybold Group
...
...