...
| 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 |
|---|
| 
|
|
|
#top5. JBI
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 |
|---|
| 
|
|
|
...
Note that normally an endpoint is identified by the combination of its service name and its endpoint name. This combination is referred to as the service endpoint.
#top5. JBI
Normalized Message Router
...
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.
#top5. JBI
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.
...
A service assembly is thus a zip of zips. It can be compared to an EAR in the J2EE world. To ease the pain of packaging the JBI artifacts, ServiceMix provides a powerful maven based tooling which can package all the JBI artifacts and generate their JBI descriptors automatically. To ease the development more, we provide maven archetypes for JBI components and service units: archetypes are templates that can generate a project in one command line (see Notes on Creating JBI Component using maven2).
#top5. JBI
Other materials
#top5. JBI
