(For more resources on this subject, see here.)

Provider—Consumer Contract

In the JBI environment, the provider and consumer always interact based on a services model. A service interface is the common aspect between them. WSDL 1.1 and 2.0 are used to define the contract through the services interface.

The following figure represents the two parts of the WSDL representation of a service:

In the Abstract Model, WSDL describes the propagation of a message through a type system. A message has sequence and cardinality specified by its Message Exchange Pattern (MEP). A Message can be a Fault Message also. An MEP is associated with one or more messages using an Operation. An Interface can contain a single Operation or a group of Operations represented in an abstract fashion—independent of wire formats and transport protocols.

An Interface in the Abstract Model is bound to a specific wire format and transport protocol via Binding. A Binding is associated with a network address in an Endpoint and a single Service in the concrete model aggregates multiple Endpoints implementing common interfaces.

Detached Message Exchange

JBI-based message exchange occurs between a Provider and Consumer in a detached fashion. This means, the Provider and Consumer never interact directly. In technical terms, they never share the same thread context of execution. Instead, the Provider and Consumer use JBI NMR as an intermediary. Thus, the Consumer sends a request message to the NMR. The NMR, using intelligent routers decides the best matched service provider and dispatches the message on behalf of the Consumer. The Provider component can be a different component or the same component as the Consumer itself. The Provider can be an SE or a BC and based on the type it will execute the business process by itself or delegate the actual processing to the remotely bound component. The response message is sent back to the NMR by the Provider, and the NMR in turn passes it back to the Consumer. This completes the message exchange.

The following figure represents the JBI-based message exchange:

There are multiple patterns by which messages are exchanged, which we will review shortly.

Provider—Consumer Role

Though a JBI component can function as a Consumer, a Provider, or as both a Consumer and Provider, there is clear cut distinction between the Provider and Consumer roles. These roles may be performed by bindings or engines, in any combination of the two. When a binding acts as a service Provider, an external service is implied. Similarly, when the binding acts as a service Consumer, an external Consumer is implied. In the same way, the use of a Service Engines in either role implies a local actor for that role.

This is shown in the following figure:

The Provider and Consumer interact with each other through the NMR. When they interact, they perform the distinct responsibilities (not necessarily in the same order).

The following is the list of responsibilities, performed by the Provider and Consumer while interacting with NMR:

1. Provider: Once deployed, the JBI activates the service provider endpoint.
2. Provider: Provider then publishes the service description in WSDL format.
3. Consumer: Consumer then discovers the required service. This can happen at design time (static binding) or run time (dynamic binding).
4. Consumer: Invokes the queried service.
5. Provider and Consumer: Send and respond to message exchanges according to the MEP, and state of the message exchange instance.
6. Provider: Provides the service by responding to the function invocations.
7. Provider and Consumer: Responds with status (fault or done) to complete the message exchange.

During run-time activation, a service provider activates the actual services it provides, making them known to the NMR. It can now route service invocations to that service.

javax.jbi.component.ComponentContext context ;
// Initialized via. AOP
javax.jbi.messaging.DeliveryChannel channel = context.
                                 getDeliveryChannel();
javax.jbi.servicedesc.ServiceEndpoint serviceEndpoint = null;
  if (service != null && endpoint != null)
  {
    serviceEndpoint = context.activateEndpoint
                          (service, endpoint);
  }

The Provider creates a WSDL described service available through an endpoint. As described in the Provider-Consumer contract, the service implements a WSDL-based interface, which is a collection of operations. The consumer creates a message exchange to send a message to invoke a particular service. Since consumers and providers only share the abstract service definition, they are decoupled from each other. Moreover, several services can implement the same WSDL interface. Hence, if a consumer sends a message for a particular interface, the JBI might find more than one endpoint conforming to the interface and can thus route to the best-fit endpoint.

Message Exchange

A message exchange is the “Message Packet” transferred between a consumer and a provider in a service invocation. It represents a container for normalized messages which are described by an exchange pattern. Thus message exchange encapsulates the following:

• Normalized message
• Message exchange metadata
• Message exchange state

Thus, message exchange is the JBI local portion of a service invocation.

Service Invocation

An end-to-end interaction between a service consumer and a service provider is a service invocation. Service consumers employ one or more service invocation patterns. Service invocation through a JBI infrastructure is based on a ‘pull’ model, where a component accepts message exchange instances when it is ready. Thus, once a message exchange instance is created, it is sent back and forth between the two participating components, and this continues till the status of the message exchange instance is either set to ‘done’ or ‘error’, and sent one last time between the two components.

Message Exchange Patterns (MEP)

Service consumers interact with service providers for message exchange employing one or more service invocation patterns. The MEP defines the names, sequence, and cardinality of messages in an exchange. There are many service invocation patterns, and, from a JBI perspective, any JBI-compliant ESB implementation must support the following four service invocations:

• One-Way: Service consumer issues a request to the service provider. No error (fault) path is provided.
• Reliable One-Way: Service consumer issues a request to the service provider. Provider may respond with a fault if it fails to process the request.
• Request-Response: Service Consumer issues a request to the service provider, with expectation of response. Provider may respond with a fault if it fails to process request.
• Request Optional-Response: Service consumer issues a request to the service provider, which may result in a response. Both consumer and provider have the option of generating a fault in response to a message received during the interaction.

The above service invocations can be mapped to four different MEPs that are listed as follows.

In-Only MEP

In-Only MEP is used for one-way exchanges. The following figure diagrammatically explains the In-Only MEP:

In the In-Only MEP normal scenario, the sequence of operations is as follows:

• Service Consumer initiates with a message.
• Service Provider responds with the status to complete the message exchange.

In the In-Only MEP normal scenario, since the Consumer issues a request to the Provider with no error (fault) path, any errors at the Provider-level will not be propagated to the Consumer.