Message-centric Web services vs. RPC-style invocations: when SOAP is a preferred method – Focus: message-centric Web services vs RPC
Chandra Venkatapathy
The notion of distributed computing has been evolving for a long time, during which we have been building business solutions by integrating various systems and platforms. Typically, these interactions are characterized by accessing and invoking clearly defined interfaces using well-known communication mechanisms like Remote Procedure Calls (RPCs) or by using message-centric protocols. Web services is probably the easiest distributed computing paradigm available today. Given the familiarity to RPC and message-centric invocation models, we need the flexibility of using both these models in the Web services invocation frameworks.
Luckily, Web services use a rather simple framework for communication–Simple Object Access Protocol (SOAP). With SOAP, you can use both message-centric invocation and RPC to invoke Web services. In this article we’ll discuss the evolution of RPC and message-centric invocations, and the pros and cons of their programming models in a service-oriented architecture.
Introduction to Web Services
Web services is nothing but a set of open standards for distributed computing and is being widely adopted by the industry. Using Web services, you can describe an existing business process as an easily consumable interface, search for other business processes as Web services components inside and outside of the enterprise, and invoke them as needed. Processes that are limited by architecture-, platform-, and language-specific implementations can be expressed as open standards-based Web services components. Using these components as building blocks, you can build robust business applications dynamically without worrying about platform, system, or enterprise boundaries, thus creating a true service-oriented architecture.
The basic invocation framework for Web services is based on SOAP, a simple, lightweight, transport-agnostic protocol that is based on XML. SOAP has evolved from RPC and messaging principles and provides support for both types of invocations. Current business applications rely on their integration infrastructure to provide robust delivery of messages and transactional integrity. Similarly, Web services -based business applications require the same messaging and transactional attributes as current applications. As SOAP is the invocation framework for Web services, we’ll discuss how these requirements are addressed later.
In order to fully understand the evolution of SOAP, it’s important to first understand the evolution of RPC and messaging systems.
Evolution of RPC
The notion of procedure calls has been in use for a long time. In the programming languages of yesteryear, we used procedure calls for programming simplicity. To kindle our nostalgia, we created modules of structured programming code and defined them as (local) procedures. We invoked these procedures with clearly defined parameters. Soon Remote Procedure Calls evolved as applications were distributed over the network. The RPC framework helped us cross the boundary of the local machine to connect to another machine to invoke a specific module with a set of parameters. Since RPCs are parametric invocations, the RPC framework has to handle the complexity of reconciling the system and language boundaries–often called “marshalling” –between the caller and the called.
In the late ’90s, XML-RPC was proposed, in which XML was used to marshal data. Given the widespread support for XML, XML-RPC offered a simplistic, yet viable invocation model over the Internet using HTTP. However, use of XML-RPC was limited as SOAP evolved rapidly and offered richer semantics than XML-RPC. Since SOAP is built on XML, you can use it to make RPC invocations. RPCs are typically used in the synchronous programming model. That is, the caller invokes a RPC on another machine, and waits for the RPC to return the results.
Evolution of Message-Centric Architecture
In a message-centric architecture, applications connect to other applications using well-defined message sets through message-oriented middleware (MOM). Initially, message-centric architecture was used to connect applications running on mainframes. As many early applications were performing batch processing, there was a need for queuing requests. Early messaging middleware offered queuing for asynchronous processing, persistence of the messages, and assured delivery in addition to connectivity. The strength of messaging middleware is determined not only by its support for the above-mentioned features, but also by support for a wide variety of platforms, languages, transport protocols, and open standards. A message-centric programming model, although used for both synchronous and asynchronous invocations, is widely known for asynchronous invocation.
Differences Between Message-Centric Invocations and RPC
The main difference between message-centric invocation and RPC lies in the programming model. RPC is a good model for function-centric invocations. As discussed earlier, it works well when we have clearly defined functions and associated parameters. The parameters can be simple data types or complex objects, in which case the objects have to be serialized as bits and bytes when traversing through the wire, often resulting in performance degradation. RPCs are typically associated with synchronous functional invocations and do not support messaging semantics such as assured delivery.
The message-centric model is frequently used for data-centric programming. That is, data is exchanged in a prescribed message format that both the sender and receiver can understand. Hence there is an emphasis on data delivery using native communication protocols and programming support to send and receive data. Often, these programming models are used for loosely coupled integration with messages and events flowing back and forth. The strength of the message-centric model lies primarily in the implementation of the messaging system, such as support for a wide variety of platforms and languages, assured delivery, persistence, support for asynchronous invocations, support for open standards, and performance. Table 1 captures the main differences.
Current SOAP engines provide interfaces for both messaging and RPC. Use of one methodology does not preclude use of another, even within the same application.
Web Services and Message-Centric Invocations
In the Web services world, messaging middleware plays an important role. The SOAP framework offers a platform-and transport-agnostic protocol to invoke Web services. However, it does not address many of the messaging semantics such as assured delivery, support for asynchronous messages, and persistence. SOAP messages can be bound to any transport, such as HTTP for example. However, the typical invocation of Web services is implemented by sending SOAP using HTTP. The problem is that HTTP does not offer assured delivery nor does it have asynchronous capabilities. If your application demands message semantics such as robust delivery of Web services and asynchronous messaging capability, you should bind SOAP-based Web services to robust messaging middleware like IBM’s WebSphere MQ.
SOAP provides the header semantics that allow intermediaries to provide higher-level functions to the message flow. Protocols have been discussed which address reliable delivery, transaction processing, correlation, routing, security, and more.. When these protocols are used as part of the SOAP messaging flow, their benefits can be achieved without changing the semantics used to invoke the Web service. In other words, these benefits can be achieved regardless of RPC or message-based invocation style.
Now that we’ve discussed the evolution of RPC and message-centric invocations, let’s look at how SOAP addresses both invocation models.
Evolution of SOAP: How You Can Do Both
SOAP is intended to be a simple yet powerful extensible protocol for distributed messaging based on XML. A key element of SOAP is its concept of having a message envelope and a set of headers. The envelope contains the message body that can be XML data or parameters and is intended for the recipient. As a SOAP message can hop through several intermediaries before it reaches its destination, the header contains routing and message-handling semantics for the intermediaries.
Another key extensibility point is that SOAP can be bound to various transport protocols. HTTP is the default binding specified within the SOAP specification and its use has been one of the key contributors to the success of SOAP. Although HTTP is the most common transport, it is by no means the only one. SOAP is designed such that its semantics are largely independent of the transport binding. This allows a client to remain unaffected if alternate transports are used. Other transports can be used to provide reliable delivery or other capabilities. Other bindings could include JMS (Java Message Service) and WebSphere MQ.
SOAP’s capabilities have provided for the transport and data format neutrality necessary for successful distributed computing. Previous distributed models such as RPC and CORBA specified more complex common data formats, but did not provide a simple and replaceable transport binding. SOAP is poised to satisfy the market need for a platform-agnostic distributed computing model.
The SOAP model has encouraged the development of follow-up specifications to enable higher-level functions. These functions include:
* Security: SOAP’s support for intermediaries requires that messages provide a means of end-to-end security, beyond the traditional transport-level security offered by SSL. The WS-Security lays the groundwork for core security constructs.
* WS-Coordination, WS-Transaction, and BPEL4WS (Business Process Execution Language for Web Services) provide transaction and business flow processing. These specifications are available from www-106.ibm.com/developerworks/ webservices/library/wsspec.html.
Invocation Model
Most SOAP implementations support both RPC and messaging interfaces. As an illustration of the differences, the following method signatures illustrate client side APIs using the Java SOAP engine Axis.
RPC-Style Invocation
Let’s take an example where a procurement application gets a quote for a purchase from a supplier. In the example discussed below, the “GetPurchaseInfo” service has a method called ‘getQuote “ForPart” with a clearly defined parameter called “PartNumber”. Typically, the underlying SOAP implementation creates a client stub for invocation that can easily be invoked from the financial application. The invocation looks just like a local method invocation as shown below, yet would invoke the method on the remote Web service:
Float f =
GetPurchageInfoStub.getQuoteForPart(String
PartNumber)
Web services provide the flexibility of dynamically determining the service signature. In this case, a stub has not been generated, and hence dynamic invocation is used. The client dynamically determines the method to call and parameters to invoke. This is conceptually similar using introspection to invoke a Java method.
Service service = new Service(new
URL(wsdl_url), serviceQN );
Call call = (Call) service.createCall(
portQN, “getQuoteForPart” );
Float flt = (Float) call.invoke( new
Object[] { “Cartridge” } );
In either case, the actual SOAP message is similar to the following:
XXX</
symbol>
Message-Centric Invocation
In a message-centric invocation, the message content is XML obtained elsewhere, such as a database. In the example, the same procurement application sends a purchase order to the supplier. A purchase order is usually a long document with various data elements well suited to representation in XML. If GetPurchaseOrder is implemented as a service, it’s easier to send the whole purchase order document rather than send each and every field as a parameter.
In the following example, a SOAP message is constructed with Purchase Order XML document and sent to the supplier using a message-style invocation.
SOAPBodyElement body = new
SOAPBodyElement( purchase order XML
document– );
call.invokeOneWay( params );
The result means nothing if the request doesn’t have a reply, or another SOAPBody Element from which the original XML is obtained. As we noted earlier, if the business case requires assured delivery of the purchase order, the SOAP message should be sent over a transport like WebSphere MQ.
Multiple-Message Invocation
Business activities are often associated with integrating services from distributed applications and are often associated with the notion of transaction. The transactional integrity is maintained by transactional systems that implement two-phase protocols. We have similar support for Web services with the announcement of specifications like WS-Coordination, WS-Transaction, and BPEL4WS.
Conclusion
SOAP provides rich semantics for RPC and message-centric invocations. As Web services are manifestations of business-critical processes, invocation of these services needs to have the same robust message and transaction semantics regardless of the style of invocation. SOAP provides the flexibility to bind with the transport of your choice and therefore can enable robust message delivery. There are ongoing efforts to provide a specification for the reliable delivery of Web services; in the meantime, several commercial implementations already support assured delivery of Web services.
TABLE 1: Difference Between RPC and Message-Centric Invocations
RPC Invocation Message-Centric Invocation
Function-centric: Aligns well Data-centric: Aligns well when there
when service invocation is is an exchange of data between
thought of as a procedural applications.
call.
Works well for data and Data need not have an object
objects that can be serialized representation. Data can be sent as a
easily. payload.
Synchronous invocation: Asynchronous invocation: Applications
Applications make a request make a request and don’t wait for any
and wait for the response. response. Instead, they rely on
events notifications.
Strong notion of message semantics
like assured delivery.
David Melgar has a background in the retail industry, systems management, Java technology, and Web services. The original author of UDDI4J, David is a member of the Emerging Technologies division of IBM software group, and focuses on Web services security within the IBM Web Services Toolkit.
DMELGAR@US.IBM.COM
Chandra Venkatapathy is a market manager for WebSphere Business Integration in the IBM software group and has been working in Web services and business integration.
CHANDRAV@US.IBM.COM
COPYRIGHT 2003 Sys-Con Publications, Inc.
COPYRIGHT 2003 Gale Group
