Message-centric vs RPC-style Web services is a long-standing debate and bone of contention regarding the proper use of Web services technologies. Early renditions of SOAP and XML-RPC were all about providing RPC-style interactions...in fact, that's all that was supported, so there really wasn't much choice in the matter.

RPC-style interfaces have their advantages: immediate gratification of request/response, and a programming model whereby remote procedures are exposed in a way that mimics the underlying object architecture of the applications concerned, allowing a developer to make "normal"-looking method calls in the native language. Are these benefits really worth it?

Developers, system architects, standards bodies, and vendors alike have all come around to the idea that message-style interactions between Web services are an attractive alternative to RPC-style Web services. It's a real pleasure to see that Web services specifications and specific implementations have matured enough to make message-centric Web services a reality. Let's examine some of the drivers that have brought on this trend:

In a business environment where Web services are being deployed as a means for linking together businesses in a value chain, message-style interactions model the way that businesses really interact with one another. These interactions have three main characteristics: loosely coupled interfaces, loosely coupled interactions, and long duration conversations. Let's use a purchase order as an example, and look at it for what it is - a document presented by a buyer to a supplier that signifies the buyer's intent to acquire, and eventually pay for, an item or list of items from the supplier.

Loosely coupled interfaces: A PO document contains all of the information necessary to fulfill the order and allow the payment process to begin - the billing information, shipping address, line item information, quantity, price, etc. A buyer needs only to send that information to a supplier once as one XML document, encapsulated inside of a message. The processing of the PO involves many discrete operations - credit check, contacting other suppliers, and so on. Loosely coupled interfaces means that each application or service in the process acts upon a self-describing XML message, extracting or modifying just the parts of the message it needs.

In a tightly coupled RPC environment, each application has to know the intimate details of how every other application wants to be communicated with - the number of methods it exposes, and the details of the parameters that each method accepts. Multiply the number of applications and services that make up an extended enterprise by the number of interfaces that each one might want to expose, and then square that. That's roughly the number of interfaces that you will have to create and maintain over time.

Loosely coupled interactions and availability: An application sends a message to another application via a message-style Web service invocation. This is part of a larger multistep process. Using message-style interactions, each step in the process is asynchronous and autonomous. If the nth receiver in the chain is not available, the initial sender is not concerned. If reliable messaging is being used in the form of JMS or WS-Reliability, then message persistence, retries, and redelivery can happen at the transport level without the applications or services even being aware that this is taking place.

In contrast, a tightly coupled RPC environment requires that all parties be available in order for the entire operation to be successful. Now take that scenario and magnify it across hundreds or thousands of interconnected endpoints and you'll see how quickly it can become an unwieldy proposition.

Long-duration conversations: The purchase order very likely was a follow-on message from a request for a price quote. The fulfillment of that order may take days, weeks, or months before all the items in the order are shipped and billing can take place. Having complete, self-describing documents as the basis for state persistence makes the separation of time irrelevant.

In contrast, a fine-grained RPC- style Web service invocation will probably not have all of the context required to span time, or even a single application session.

Data transformation and routing: Every application has its own way of internally representing data, and not all business partners are going to agree on the same dialect of XML. The availability of a self-contained XML document at all times lends itself very well to utilizing XSLT for translation to target data formats, and XPATH for routing of messages based on their content

When all is said and done, the benefits of message-centric Web services far outweigh the perceived advantages of RPC. So get on board, and get messaging!