SOAP Protocol Primary Guide

SOAP (Simple Object access protocal) technology helps to achieve interoperability between a large number of heterogeneous programs and platforms so that existing applications can be accessed by a wide range of users. SOAP combines the flexibility and scalability of a sophisticated HTTP based Web technology with XML.

This article takes you through a comprehensive review of the process of object remote process invocation (ORPC) technology to help you understand the basics of soap technology and how it overcomes many of the pitfalls of existing technologies such as CORBA and DCOM. It then describes the detailed soap coding rules and focuses on how SOAP maps to the existence of the ORPC concept.

Introduction:

When I started computing as my career in 1984, most programmers didn't care about network protocols. But in the 90 's, the web became ubiquitous, and now it's hard to imagine anyone using a computer but not using some form of network connectivity. Today, the average programmer is more interested in building scalable, distributed applications, rather than focusing on coolbars, a floating translucent, non rectangular rectangle, that uses MFC to personalize it.

Programmers often prefer to use programming models to think about problems, and rarely consider network protocols. Although this is usually a good thing to do, the soap I will discuss in this article is a network protocol with no obvious programming model. This does not mean that the architecture of soap fundamentally alters the way you program. Instead, one of the main goals of soap is to make existing applications available to a wider range of users. For this purpose, there is no SOAP API or SOAP object request proxy (Soap ORB), and soap is a technique that assumes that you will use as many existing technologies as possible. Several major CORBA vendors have pledged to support the SOAP protocol in their ORB products. Microsoft is also committed to supporting SOAP in future COM versions.

DevelopMentor has developed a reference implementation that allows soap to be used by any Java or Perl programmer on any platform.

The idea behind soap is "it's the first technology that hasn't invented any new technology". SOAP employs two protocols that have been widely used: HTTP and XML. HTTP is used to implement the RPC-style transport of soap, and XML is its encoding pattern. With a few lines of code and an XML parser, HTTP servers (such as MS IIS or Apache) immediately become soap orbs. Because more than half of the Web servers currently use IIS or Apache, SOAP will benefit from the extensive and reliable use of both products. This does not mean that all SOAP requests must be routed through a Web server, and that traditional Web servers are just one way of assigning soap requests. Therefore, Web services such as IIS or Apache are sufficient to establish SOAP-enabled applications, but are by no means necessary.

As this article will describe, soap simply encodes the HTTP transport content with XML. The most common application of soap is as an RPC protocol. In order to understand how soap works, it is necessary to briefly review the history of RPC protocols.

The history of RPCs

The two main communication models for building distributed applications are message delivery (often grouped together with queues) and request/response. The messaging system allows any party to send messages at any time. The request/Response protocol restricts the communication mode to both sides of the request/response. Message based applications are acutely aware that they are communicating with external parallel processes and need an explicit design style. Application based on request/response is more like a single process, because the application of sending requests is more or less blocked until a response from another process is received. This makes the request/response communication naturally appropriate for RPC applications.

Although message communication and request/response have their merits, they can be implemented with each other. Message systems can be built with a lower-level request/response protocol. A DCE RPC is used internally by Microsoft's message Queue Server (MSMQ) to establish most of the control logic. RPC systems can also be built using a lower-level message system. The association ID provided by MSMQ is for this purpose. Regardless of the evaluation, most applications still tend to use RPC protocols because they are widely used, they are simpler to design, and more natural to the mapping of traditional programming techniques.

In the 80 's, two major RPC protocols were Sun RPC and DCE RPC. The most popular Sun RPC application is the network File system (NFS) used by most Unix systems. The most popular DCE RPC application is Windows NT, which uses the DCE RPC protocol to implement many system services. These two protocols are proven to be applicable to a wide range of applications. However, in the late 80, the popularity of object-oriented technology has made the software industry addicted to building a link between object-oriented language and RPC based communication.

The object RPC (ORPC) protocol, which was generated in the 90 generation, is an attempt to link object-oriented and network protocols. The main difference between the ORPC and RPC protocols is that the ORPC code maps from a communication terminal to a language-level object. There is a cookie in the header of each ORPC request, which can be used by the server-side program to locate the target object in the server process. Usually this cookie is just an array of indexes, but other techniques are often used, such as the key to the hash table with the symbol name.

Currently, the two major OPRC protocols are DCOM and CORBA's Internet Inter-ORB Protocol (IIOP) or more general Inter-ORB Protocol (GIOP). The request format for DCOM and IIOP/GIOP is very similar. All two protocols use an object endpoint ID to determine the target object and use the method identifier to determine which method to invoke.

There are two main differences between the two protocols: the main difference is that when IIOP/GIOP is used, the interface identifier is implied, because a given CORBA object implements only one interface (although the OMG is currently working on a standardized work that has multiple interfaces supported for each object). Another subtle difference between DCOM and IIOP/GIOP requests is the format of the parameter values in the transport body. In DCOM, the transport body is written in the form of a network data expression (NDR) in which the IIOP/GIOP is written in the form of a public data expression (CDR). NDRs and CDR handle different data representations on a variety of platforms, respectively. But there are some small differences between the two formats that make them incompatible with each other.

Another important difference between ORPC and RPC protocols is the way in which communication endpoints are named. In the ORPC protocol, some transitive representations of ORPC endpoints are required to pass object references between networks. In Corba/iiop, this expression is referred to as an interactive object reference (IOR). Iors contains addressing information expressed in a compact format and uses it to determine an object endpoint for any CORBA product. In DCOM, this expression is called ObjRef, which combines the reference calculation of a distribution and the endpoint/object identity. Both CORBA and DCOM provide advanced mechanisms for finding object endpoints on the network, but eventually these mechanisms are mapped back to iors or objrefs.