Web Services Messaging with Apache Axis2: Concepts and Techniques

by Srinath Perera, Ajith Ranabahu
07/27/2005

Until recently, web service interactions were solely synchronous and request-response in nature. However, it soon became clear that the synchronous request-response type of interaction is a very small subset of messaging scenarios. Messaging is very important in constructing loosely coupled systems, and as a result, this limitation is critical. Web service specifications, such as WS-addressing and WSDL, have incorporated the concepts of messaging, and lay the foundation to cover a wider range of messaging scenarios. The Apache Axis2 architecture assumes neither one message exchange pattern, nor synchronous/asynchronous behavior. This article explains messaging concepts and how Axis2 can be used to implement several well-known messaging scenarios.

A Brief Introduction to Messaging

Throughout the history of computing, one of the greatest challenges has been in distributed computing: when the resources are distributed, interprocess communication becomes quite difficult. Researchers are still looking for better solutions. Interestingly, almost all of the solutions for the problem of distributing computer power emerge from two conceptual bases: remote procedure calls (RPC) and messaging.

Unquestionably, using RPCs is the more popular technique among developers, partly due to its resemblance to using local procedure calls. It has an air of familiarity for programmers, and creates a natural tendency towards using RPC style in a distributed system. Messaging, on the other hand, is not remarkably popular, and quite a few developers are likely to raise their eyebrows if it is mentioned. Nevertheless, messaging provides certain advantages over RPC systems in certain scenarios.

The fundamental differences between RPC and messaging frameworks are as follows.

• Messaging has no notion of client and server. Since a messaging framework (also known as message-oriented middleware, or MOM) concentrates on delivering a message, all nodes that accept and emit messages are considered equal in status and termed peers. RPC always has the concepts of the service requester (AKA client) and service provider (AKA server).
• Messaging is time-independent, to a certain extent. None of the peers are expected to accept the message in real time--MOM takes care of delivering a message to the relevant peer when it is available. RPC, however, fails instantly when one party goes down.
• Messages can be duplicated and delivered to multiple peers quite easily. While RPC is essentially a one-with-one communication strategy, messaging is far more flexible and can deliver copies of the same message to multiple peers without any effort from the emitter.

Web Service Messaging

Web services are defined based on XML messaging, and the following three parameters describe a given web service's messaging interaction.

1. Message exchange pattern
2. Synchronous and asynchronous client API
3. One-way/two-way behavior of the transport

Related Reading Java Web Services in a Nutshell By Kim Topley

In the most abstract form, web service messaging is based on sending and receiving messages. A given message is sent by one party, and received by a another. The messages might be related to each other, and it is important to identify the most common use cases among those related groups of messages; such message groups are defined as message exchange patterns, or MEPs.

A service requester's behavior in the transient period between two related messages defines the synchronous/asynchronous behavior in the client API. In the synchronous case, invocation at the client API would block, and wait until the related message arrives at the destination. In the non-blocking case, the client invocation continues without blocking, and when a related message arrives, it is correlated with earlier messages.

Transports are categorized as one-way or two-way, based on simplex or duplex behavior. Transports like SMTP and JMS are one-way transports, and are non-blocking in nature. On the other hand, transports like HTTP and TCP are two-way, and the related message may travel back in the return channel. Actually, in web service messaging, two-way transports may be used as a one-way transports, but in such cases, they can be effectively treated as one-way.

Message Exchange Patterns

According to the W3C recommendation, a message exchange pattern is a template that establishes a pattern for the exchange of messages between two communicating parties. A MEP identifies a common grouping of related messages. The MEPs are defined based on the service requester and service provider, and it is important to note that the MEPs are named based on message characteristics in the service provider, for the sake of clarity. All of the names can be understood by replacing the in with request and out with response.

For an example, let us consider two well-known MEPs.

1. In-only/"fire and forget:" The service requester sends a message to the service provider and does not expect any related message.
2. In-out/"request response:" The service requester sends a message to the service provider and expects a response.

The concept of MEPs is still evolving, and the number of patterns is unlimited, so web service middleware implementations are compelled to implement only a few chosen MEPs. "Fire and forget" and "request-response" are the ones that are used explicitly, and most other patterns can be constructed using these two.

Pages: 1, 2, 3, 4

Next Page