Basic Guide to SOAP protocol

Http://www.yesky.com/229/1739729.shtml
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 mature HTTP-based Web technology with the flexibility and scalability of XML.

This article provides a comprehensive review of the process of Object Remote Process calling (orpc) technology to help you understand the foundation of the soap technology and overcome existing technologies (such as CORBA and DCOM) methods for many defects. Then we will introduce the detailed soap encoding rules and focus on how soap maps to the existing orpc concept.
Introduction:

When I started using computing as my career in 1984, most programmers did not care about network protocols. However, in 1990s, networks became ubiquitous. It is hard to imagine who is using computers but not using some form of network connection. Today, General programmers are more interested in building Scalable Distributed applications, instead of simply focusing on using MFC to implement personalized floating translucent non-rectangular coolbars.

Programmers usually like to think about problems using programming models, but seldom consider network protocols. Although this is usually good, the soap I will discuss in this article is a network protocol without obvious programming models. This does not mean that the soap architecture will fundamentally change the way you program. On the contrary, a major goal of soap is to make existing applications more widely used by users. For this purpose, there is no soap API or soap Object Request proxy (soap orb). Soap assumes that you will use as many existing technologies as possible. Several major CORBA vendors have promised to support the SOAP protocol in their ORB products. Microsoft also promises to support soap in future com versions.

DevelopMentor has developed a reference implementation that allows any Java or Perl programmer on any platform to use SOAP.

The guiding philosophy behind SOAP is "it is the first technology that has not invented any new technology ". SOAP uses two widely used protocols: HTTP and XML. HTTP is used to implement RPC-style transmission of SOAP, and XML is its encoding mode. Using several lines of code and an XML parser, the HTTP server (such as MS's IIS or Apache) immediately becomes the SOAP ORBs. Because more than half of the Web servers currently use IIS or Apache, SOAP will benefit from the wide and reliable use of these two products. This does not mean that all SOAP requests must be routed through the Web server. The traditional Web Server only distributes SOAP requests. Therefore, Web services such as IIS or Apache are sufficient for creating SOAP-enabled applications, but they are not necessary.

As described in this article, SOAP simply uses XML to encode HTTP transmission content. The most common application of SOAP is as an RPC protocol. To understand how SOAP works, it is necessary to briefly review the history of RPC.

　　RPCs history

Two main communication models for building distributed applications are message transmission (often combined with queues) and request/response. The message passing system allows any party to send messages at any time. The request/response protocol limits the communication mode to both parties in the request/response. Message-based applications are strongly aware that they are communicating with external parallel processes and require an explicit design style. A request/response-based application is more like a single process application, because the application sending the request is more or less blocked until it receives a response from another process. This makes request/response communication suitable for RPC applications.

Although message communication and request/response have their own advantages, they can all be implemented by the other party. The message system can be established using a lower-layer request/response protocol. For example, Microsoft's Message Queue Server (MSMQ) uses dce rpc to establish most of the control logic. The RPC system can also be built using a lower-level message system. The Association ID provided by MSMQ is for this purpose. Regardless of the rating, most applications tend to use RPC because they are widely used, they are simpler to design, and more naturally mapped to traditional programming technologies.

In 1980s, 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 ?, It uses the dce rpc Protocol to implement many system services. These two protocols have proved to be applicable to a wide range of applications. However, in the late 1980s S, the popularity of object-oriented technology made the software industry addicted to establishing a bond between object-oriented language and RPC-based communication.

The object RPC (ORPC) protocol, which was generated in 1990s, attempts to associate object-oriented with network protocols. The main difference between ORPC and RPC is that ORPC code maps objects from communication terminals to languages. Each ORPC request header contains a cookie, which can be used by the server program to locate the target object in the server process. This cookie is usually only an index on the array, but other technologies are often used, such as using the symbol name as the key of the Hash table.

Currently, the two major OPRC protocols are DCOM and CORBA Internet Inter-ORB Protocol (IIOP) or General Inter-ORB Protocol (GIOP ). The request formats of DCOM and IIOP/GIOP are very similar. Both protocols use an object endpoint ID to determine the target object and a method identifier to determine which method to call.

The two protocols have two major differences: The main difference is that when IIOP/GIOP is used, the interface identifier is implicit, because a given CORBA object only implements one interface (although OMG is currently standardizing each object with multiple interfaces ). Another subtle difference between DCOM and IIOP/GIOP requests is the format of parameter values in the transport body. In DCOM, the transport body is written in the format of network data expression (NDR). In IIOP/GIOP, the transport body is written in the format of public data expression (CDR. NDR And CDR process different data expressions on different platforms respectively. However, there are some minor differences between the two formats, which makes them incompatible with each other.

Another important difference between the ORPC and RPC protocols is the communication endpoint naming method. In the ORPC protocol, it is required to transmit object references between networks for some deliverable expressions of ORPC endpoints. In CORBA/IIOP, this expression is called an interactive object reference (IOR ). IORs contains addressing information expressed in a compact format. any of its CORBA products can determine an object endpoint. In DCOM, this expression is called OBJREF, which combines distributed reference computing and Endpoint/object identifiers. Both CORBA and DCOM provide advanced mechanisms for finding object endpoints on the network, but these mechanisms are mapped back to IORs or OBJREFs.