Document Exchange vs. RPC models
One of the very first things that must be decided in your architecture is whether you will use RPC-encoded or document-style interactions. Your choice can impact the level of coupling present in your architecture.

An RPC (remote procedure call) is essentially a call to a remote method. Web services are XML-based, but you can still interact with the back-end service in an RPC-like fashion. Typically, the interaction is a very simple request/response, where the client sends a SOAP message that contains a call to a method. The application server receiving this request can then translate this request into the back-end object (e.g., a Java object, EJB method, or C# method). There is very little that developers have to do to build an RPC-based Web service because everything is mapped for them. Note that even in this approach XML is used to contain the call.

With document style, XML "business documents" are transmitted across the wire. They do not map directly to back-end method calls; they are actually complete, self-contained business documents. When the service receives the XML document, it might do some pre-processing on the document, perform some work, and construct the response back. There is usually no direct mapping to a back-end object. In fact, a request might invoke multiple components on the back end. The developer has to do much of the work in processing and mapping the XML data received, and there are very few tools on the market that can do this automatically. The document style is typically used in conjunction with asynchronous protocols to provide reliable, loosely coupled architectures.

A good analogy for illustrating RPC vs. document style is the difference between making a phone call and sending an email message. When making a phone call with no voicemail available, you are expecting some one on the other end to pick up and begin talking to you. This is very much a request-response paradigm and maps well to RPC-style messaging. On the other hand, sending an email doesn't require the sender to be there. The email, or business document, which has all the information it needs, can wait in a queue or mail server until the receiver wants to read it. This is analogous to the document style interaction.

The general recommendation is to use document style messaging in your architectures. While an RPC approach can be implemented rather quickly, it will not be sufficient down the road when you have to interact with suppliers, customers, and partners who are beyond your control. In these situations, you will want an architecture that shields you (and the clients) as much as possible from the back-end implementation. Figure 3 shows the architectural differences between RPC and document style messaging.

Figure 3: Document vs. RPC. Unlike document style messaging, RPC messaging requires an immediate response from the recipient.

Document style messaging delivers a number of benefits:

• With document style, you can utilize the full capabilities of XML to describe and validate a business document. With the RPC approach, the XML typically just describes the methods and parameters of the method call.
• It does not require a tight contract between the client and the service provider. RPC is typically static, requiring changes to the client when the method signature changes. With document style, the rules can be less rigid.
• Because it is self-contained, document style is typically better suited for asynchronous processing.

There is one key disadvantage to document style—it is typically more difficult to implement than an RPC approach. Despite this fact, the flexibility gains well outweigh the implementation costs. And more and more vendors are beginning to provide some support for the document style approach. Document style is also recommended over the RPC approach by organizations such as the WS-I.

Submit article to: