...
| Info |
|---|
|
In the mean time, you will find some good articles on the ServiceMix web site |
Overview
What is JBI ?
| Section |
|---|
| Column |
|---|
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. |
| Column |
|---|
| Panel |
|---|
| borderColor | #ccc |
|---|
| bgColor | #ffffff |
|---|
| title | JBI plugin framework |
|---|
| borderStyle | solid |
|---|
|  Image Added
|
| Panel |
|---|
| borderColor | #ccc |
|---|
| bgColor | #ffffff |
|---|
| title | JBI decoupling |
|---|
| borderStyle | solid |
|---|
|  Image Added
|
|
|
JBI Architecture
| Section |
|---|
| Column |
|---|
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: - Installing components
- Managing a component's life cycle (start / stop)
- Deploying service artifacts to components
JBI components often function as a type of container to which artifacts can be deployed to add new service or provider logic. For example, a service engine that provides XSLT-based transformation services would have XSLT style sheets deployed to it, in order to add new transformation operations. This process of adding such component-specific artifacts to an installed component is called deployment, to distinguish it from component installation. Such an artifact is called a service unit, while collection of deployment artifacts and associated metadata is called a service assembly.
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. |
| Column |
|---|
| Panel |
|---|
| borderColor | #ccc |
|---|
| bgColor | #ffffff |
|---|
| title | JBI Architecture |
|---|
| borderStyle | solid |
|---|
|  Image Added
|
|
|
#top
WSDL messaging model
| Section |
|---|
| Column |
|---|
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)
|
| Column |
|---|
| Panel |
|---|
| borderColor | #ccc |
|---|
| bgColor | #ffffff |
|---|
| title | WSDL Messaging Model |
|---|
| borderStyle | solid |
|---|
|  Image Added
|
|
|
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.
...
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
A Delivery Channel is a bidirectional asynchronous communication pipes between a component and the NMR.
A service consumer uses its delivery channel to initiate a service invocation, while the provider uses its delivery channel to receive such invocations.
Each component is provided with a single delivery channel, so the same channel is used for both inbound and outbound communications.
...
The activation is split in two steps"
- Declaring a service endpoint (service QName + endpoint name)
- Providing metadata: the component has to provide a WSDL description of the activate endpoint
The WSDL description will be used by the NMR to know which interfaces and operations are implemented by the activated endpoint.
Service invocation and MEP
...
- Implicitly: the NMR selects the endpoint based on the service type required
- Explicitly: a consumer chooses the endpoint based on its own logic and configuration
- Dynamically: an endpoint reference (EPR) is used within a message exchange to provide a " call-back" address that the service provider should use to send further message exchanges. EPRs are xml fragment created and resolved by JBI components.
Invocation example
This sequence diagram shows a InOut service invocation between a consumer and a provider.
- The consumer creates an InOut message exchange, populates the "in" message (the request) and send it to the NMR
- The provider component polls the delivery channel for an exchange
- It processes the request, populates the "out" message and send it back to the NMR
- The consumer polls the delivery channel for the response
- It processes the response and mark the exchange as "done"
- The provider receives the "done" status from the delivery channel
| Panel |
|---|
| borderColor | #ccc |
|---|
| bgColor | #ffffff |
|---|
| title | WSDL Messaging Model |
|---|
| borderStyle | solid |
|---|
|
 Image Added
|
This example is an asynchronous invocation, but JBI also handles synchronous calls. In such a case, the consumer call to send would be a sendSync and would block the thread until the response is received. On the provider side, if the provider wish to synchronously deliver the response, the call to send (#3) would block until the consumer acks the response.
When an exchange involves a binding component, either as a consumer or a provider, the same diagram applies. The difference is that the exchange creation would be triggered by an external request (a JMS message, or an HTTP request) before step #1 and send the response after step #4. If the provider is a binding component which proxies a remote service, it would invoke the service between the steps #2 and #3.
People may wonder why there is a need for a "done" status... In JBI, all exchanges are terminated by either a "done" or an "error" status. Errors are different from faults which are parts of the normal exchange processing. So, the done status is very useful to implement reliable message, transactions or passing streams inside the exchange.
Let's take the example a file binding component, which would poll for files, send the content as an InOnly request, and delete them afterwards. For performance reasons, it will send an opened stream on the file, but it has to close the stream and delete the file once processed. If the consumer is asynchronous (which is better because it saves threads), it needs a way to know when the file has to be deleted, hence the need for the "done" status.
#top
JBI packaging
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.
...
