Basic Guide to SOAP protocol (1)

Soap (Simple Object Access Protocal) technology helps to achieve a large number of heterogeneous Program And platform interoperability, 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 articleArticleThis document 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. Several rowsCodeWith 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 Internet Inter-ORB Protocol (iiiop) for DCOM and CORBA, or general inter--General general-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.
 
Current technical problems?

Although both DCOM and IIOP are fixed protocols, the industry has not completely switched to any of them. The lack of integration is partly due to cultural issues. And when organizations try to standardize one or another, the Technical Applicability of the two Protocols will be challenged. Traditionally, both DCOM and CORBA are considered reasonable server-to-server communication protocols. However, both of them have obvious weaknesses in communication between the client and the server, especially when the client is spread over the Internet.

Both DCOM and CORBA/IIOP rely on a single vendor's solution to use the Protocol with the greatest advantage. Although both protocols have been implemented on various platforms and products, the reality is that the selected release needs to be implemented by a single vendor. In the case of DCOM, this means that each machine runs on Windows NT. (Although DCOM has been transferred to another platform, it is only in windows? ). In the case of CORBA, this means that each machine needs to run the same ORB product. It is indeed possible that two CORBA products use IIOP to call each other, but many advanced services (such as security and transactions) are usually not interactive at this time. Moreover, the optimization made by any specialized vendor for the communication of the same machine is difficult to work, unless all applications are built on the same ORB product.

Both DCOM and CORBA/IIOP depend on well-managed environments. Two arbitrary computers have a low probability that DCOM or IIOP will be successfully called out of the box outside the environment. This is especially true for security considerations. Although it is possible to write a shrink-wrap application that can successfully use DCOM or IIOP, this is more detailed than socket-based applications. This is especially useful for tedious but necessary configuration and installation management tasks.

Both DCOM and CORBA/IIOP depend on a very high-tech operating environment. Although the COM in the process seems very simple, the COM/DCOM remote processing program is definitely not just a few days to solve the problem. IIOP is a protocol that is easier to implement than DCOM, but both protocols have a lot of Esoteric rules to process data arrangement, type information, and bit operations. This makes it very difficult for general programmers to construct a simple call to the CORBA or DCOM without understanding the ORB product or ole32.dll.

Perhaps the most intolerable thing for DCOM and CORBA/IIOP is that they cannot play a role on the Internet. For DCOM, it is almost impossible for an iMac or a cheap PC compatible machine running Windows 95 to use your server for domain-based authentication. Worse, if the firewall or proxy server separates the client and server machines, the possibility of any IIOP or DCOM package passing is very low, most internet connection technologies prefer HTTP. Although some vendors such as Microsoft, Iona, and Visigenic have established channel technologies, these products are easy to be sensitive to configuration errors and cannot interact with each other.

In a server community, these problems do not affect the use of DCOM or IIOP. Because the number of hosts in the server community is very small (usually hundreds, not thousands), this offset the cost of DCOM Ping-based lifecycle management. In the server community, all hosts are highly likely to be managed by one public management domain, making unified configuration possible. A relatively small number of machines can also maintain the controllable cost of commercial orb products, because only a smaller number of ORB licenses are required. If only IIOP is used in the server community, a small amount of ORB permission is required. Finally, it is possible that all hosts in the server community have direct IP connections, which eliminates the DCOM and IIOP problems related to the firewall.

HTTP as a better RPC

Using DCOM and CORBA in the server community is a common practice, but the client uses http to access the server community. The HTTP protocol is similar to the RPC protocol. It is simple and widely configured, and is easier to use for firewalls than other protocols. HTTP requests are generally handled by web server software (such as IIS and Apache), but more and more Application Server products are supporting HTTP as another protocol except DCOM and IIOP.

Like DCOM and IIOP, the HTTP layer uses TCP/IP for Request/response communication. An HTTP client connects to the HTTP server over TCP. The standard port number used in HTTP is 80, but any other port can also be used. After a TCP connection is established, the client can send a request message to the server. The server sends an HTTP Response Message to the client after processing the request. Request and response messages can contain information of any transmission body. They are usually marked with the HTTP headers of Content-Length and Content-Type. The following is a valid HTTP Request Message:

Post/foobar HTTP/1.1
HOST: 209.110.197.12
Content-Type: text/plain
Content-Length: 12
Hello, world

You may have noticed that the HTTP header is only plain text. This makes it easier to diagnose HTTP problems by using a packet inspection program or text-based Internet tool (such as telnet. HTTP text-based attributes make HTTP more suitable for low-tech programming environments popular in Web development.

The first line of an HTTP request contains three components: HTTP method, request-Uri, and Protocol version. In the previous example, these correspond to post,/foobar, and HTTP/1.1 respectively. Internet Engineering Task Groups (IETF) have standardized a fixed number of HTTP methods. Get is the method used by HTTP to access the Web. Post is the most common HTTP method for building applications. Unlike get, post allows arbitrary data to be sent from the client to the server. The request URI (Uniform Resource Identifier) is an HTTP server software used to identify the simple identifier of the Request target (it is more like an IIOP/GIOP object_key or a DCOM ipid ). For more information about Uris, see "URIs, URLs, and urns ". In this example, the Protocol version is HTTP/1.1, which indicates that the Protocol complies with RFC 2616 rules. HTTP/1.1 adds several more features than HTTP/1.0, including support for mass data transmission and support for TCP connections between several HTTP requests.

The third and fourth rows of the Request specify the size and type of the Request body. The Content-Length header specifies the number of bytes of the body information. The Content-Type identifier specifies the MIME type as the body information syntax. HTTP (like DCE) allows the server to negotiate with the client to compile the transmission Syntax of information. Most DCE applications use NDR .. Most Web applications use text/HTML or other text-based syntax.

Note the empty line between the Content-Length header and the request body in the preceding example. Different HTTP headers are defined by carriage-return/line code sequence. Use another carriage-return/line code sequence between these headers and the body to define the boundary. The request is followed by the original bytes. the syntax and length of these bytes are identified by the Content-Length and Content-Type HTTP headers. In this example, the content is a 12-byte normal text string "Hello, world ".

After the request is processed, the HTTP server is expected to send an HTTP Response to the client. The response must contain a status code to indicate the request results. The response can also contain arbitrary body information. The following is an HTTP Response Message:

200 OK
Content-Type: text/plain
Content-Length: 12
Dlrow, olleh

In this example, the server returns status code 200, which is a standard success code in HTTP. If the server cannot crack the request code, it will return the following response:

400 bad request
Content-Length: 0

If the HTTP server decides that the request to the target URI should be switched to another URI temporarily, the following response will be returned:

307 temporarily moved
Location: http: // 209.110.197.44/foobar
Content-Length: 0

This response informs the customer that the request will be satisfied by re-passing it to the address specified in the location header.

All standard status codes and headers are described in RFC 2616. Few of them are directly related to soap users, but there is an obvious exception. In HTTP/1.1, the underlying TCP connection is reused among multiple request/response pairs. The HTTP connection header allows either client or server to close the underlying connection. By adding the following HTTP headers to the request or response, both parties require that their TCP connections be closed after processing the request:

Connection: Close

To maintain TCP connections when interacting with HTTP/1.0 software, it is recommended that the sender Add the following HTTP headers to each request or response:

Connection: keep-alive

This header makes the default HTTP/1.0 protocol unusable when the TCP connection is restarted after each response.

One advantage of HTTP is that it is widely used and accepted. Figure 4 shows a simple Java program that sends the preceding request and parses the result string from the response.

The following is a simple C program that uses CGI to read the string from the HTTP request and return its reverse string through the HTTP response.

# Include <stdio. h>
Int main (INT argc, char ** argv ){
Char Buf [4096];
Int cb = read (0, Buf, sizeof (BUF ));
Buf [CB] = 0;
Strrev (BUF );
Printf ("200 OK \ r \ n"); P>
Printf ("Content-Type: text/plain \ r \ n ");
Printf ("Content-Length: % d \ r \ n", CB );
Printf ("\ r \ n ");
Printf (BUF );
Return 0;

The server uses Java Servlet to avoid the overhead of one process for each CGI request.

generally, CGI is the method for writing HTTP server code with the minimum cost. In fact, each HTTP server product provides a more effective mechanism for your code to process an HTTP request. IIS provides ASP and ISAPI as mechanisms for writing HTTP code. Apache allows you to write modules using C or Perl running in the Apache background program. Most application server software allows you to write Java Servlet, COM components, EJB session beans, or CORBA servants based on the Portable Object Adapter (PoA) interface.