Service description, invocation, and message exchanges

We’ve talked a bit about message exchanges and you’ve seen how messages are exchanged from a high-level point of view. In this section, we dive a bit deeper into the message exchanges and explore how they’re defined and how a consumer can cre- ate a message exchange.

We’ve already talked about consumers and providers. A provider provides a certain service, and a consumer can consume that service. But how can the consumer tell what kind of operations you can invoke on a certain provider, what do the messages look like that need to be sent, and what kind of errors can you expect? There are two possible sources to get more details about the interface of a service provider. The first one is the obvious one: just look closely at the documentation and determine which operation is provided and what kind of messages can be sent. There is, however, also a more dynamic way of doing this: self-describing services.

Let’s quickly look at what the JBI specs have to say about this:

[S]ervice providers declare to the NMR the particular services they provide. Each declaration must be accompanied by a corresponding metadata definition, which describes the declaration. (This metadata definition is supplied by a Component-supplied SPI.) JBI requires that WSDL 1.1 or WSDL 2.0 be used for all such declarations. The NMR presumes (but does not enforce) that all such declarations are compliant with the WSDL specifications. However, if the metadata is malformed, it is a likely consequence that service consumers will be unable to properly invoke the service.

Message exchange patterns

The message exchange patterns described here aren’t specific to JBI. The patterns are the same ones defined in the Web Services Description Language (WSDL) 2.0 specification. JBI only uses the four patterns we described earlier. However, the specification defines a couple of extra patterns (http://www.w3.org/TR/2004/ WD-wsdl20-patterns-20040326) that aren’t used in JBI. As you can see from the previous patterns, they’re all written from the perspective of the provider. For instance, when we look at the In-Out pattern, the provider receives an incoming message and sends a message back to the consumer. Alternatively, the provider only receives a message and doesn’t send anything back (the In-Only pattern).

The WSDL 2.0 specification also specifies message exchange patterns the other way around. These are exchanges that are initiated by the provider and, just like the other patterns, are written from the provider point of view. So instead of the In-Only pattern, you also get the Out-Only pattern. You should consider these kinds of messages to be event messages; for instance, a certain service provider can notify its consumers that it’s going offline for an hour, or send out warnings or other events.

What this says is that each provider should publish its service description to the nor- malized message router as a WSDL 1.1 or WSDL 2.0 document. However, the NMR

doesn’t check whether or not they are valid. Figure 2.10 illustrates the publication and consumption of services.

As you can see in figure 2.10, a provider can publish a service on the NMR and a consumer can consume this service. Knowing this, you can simply tell a consumer to look up the service description for a certain service endpoint and the consu- mer will know what kind of operations are supported and the type of messages that can be sent.

Now that you know how to determine what kind of operations and messages a ser- vice provides, let’s see how a consumer can create a message exchange with a cer- tain provider.

Abstract and concrete WSDL

A WSDL 2.0 document is split into an abstract part and a concrete part. The abstract part defines the operations, the messages, and the XML structures a service implements. The concrete part shows how the operations can be called (such as SOAP over JMS, or by using a file in a certain directory). You can view the abstract WSDL as a Java interface definition and the concrete part as the implementation.

When you consider this from the JBI point of view, the abstract part of the WSDL is used inside the NMR. When you look up a certain description for a provider, you’ll only need the abstract part to determine how to invoke a certain service. The concrete part is often used to configure business components and service engines. For instance, Open ESB uses the concrete part of a WSDL to configure its JBI components.

Figure 2.10 An overview of the publication and consumption of services via the normalized message router. A provider publishes a service on the NMR and a consumer can consume this service.

Invoking a certain operation on a provider isn’t that hard. You simply create a new MessageExchangeFactory for a certain service or interface. Using this factory, you create an exchange for a specific operation. Once you have the message exchange, just set the correct message and pass it on the NMR. The NMR will route the message to the correct service. This might all seem a bit complex, but you don’t have to worry. All the JBI-based ESBs out there provide a large set of components so usually you don’t have to be concerned with these internals, unless you’re writing your own SEs or BCs.

You’ve now seen how the services can communicate with one another, which roles services can have, and what service engines and binding components do. In the next section we show how you can deploy artifacts to service engines and bind- ing components.