About SOAP coding
Release Date: 4/1/2004
| Update Date: 4/1/2004
Tim Ewald
Microsoft Corporation
October 2002
Abstract: This article describes the SOAP encoding left by SOAP history (also known as "Section 5 Coding") why there is no foothold in the future development of Web services.
Introduction to SOAP's development history and core specific example of Web service issues solve the problem of encoding
Introduction
SOAP is the cornerstone of the Basic Web Service Protocol Stack. The SOAP specification is officially confirmed to use the XML message as a communication method. It defines a scalability model, a method of representing protocols and application errors, multiple rules that send messages through HTTP and multiple principles that map RPC to SOAP messages. It is useful to use standard methods to perform these operations. Otherwise, each developer who wants to send XML messages through HTTP will have to create their own specific solutions for these issues, so that interoperability is difficult to implement. Although most of the content of the SOAP specification is good, there is one of them: SOAP encoding. SOAP encoding (according to the definition of this coding method in the SOAP 1.1 specification, sometimes referred to as "Section 5 encoding") is a problem left by SOAP history, which is not based in the future of Web services. This article will explain the reasons, let us first review history.
Back to top
SOAP development history and web services
When writing the first SOAP specification, the various concepts behind the web service are still in the germination phase. It is planned to use SOAP to better integrate distributed object techniques (eg, DCOM, CORBA, and RMI) with this machine's Internet technology (eg, XML, and HTTP). The goal is to establish a pipe to create and use XML-based messages without using a variety of binary message formats supported by different techniques (names NDR, CDR, and JRMP).
In order to create and use messages in a distributed application, they need to know what these messages should look like. Most distributed object systems demonstrate the combination of binary representations of Compilation Proxy / Stubleton and metadata (eg, COM type library, CORBA interface library, or java .class file). SOAP has not changed this. The authors of the SOAP specification assume that the application developer will ensure that the client and server have any information required to properly handle the SOAP message.
However, the SOAP authors recognize that if you do not intend to define a generic method to describe the message, then at least you should provide some guidance on how to map the universal object-oriented programming structure to XML. They can't use the XML architecture (XSD) to solve this problem because the XSD is far from completion. Thus, they define a data model based on the diagram of the non-type structure. Then they wrote the SOAP coding rule, explained how to sequence the instance of the SOAP data model into SOAP messages. The work that maps the specific technology to the SOAP data model is left to the implementation.
As SOAP has received the attention of the industry, a new requirement has emerged. Developers want to download instructions on message formats about the SOAP server so that they can create a client to talk to their conversations. Because the server wants to provide this description does not have any assumptions for creating a client, it is not possible to disclose the information in existing metadata formats (eg, type libraries). The solution to this problem is to use a universal metadata format that is portable as SOAP itself, that is, WSDL. WSDL uses PortType to clear the behavior supported by a Web service. PortType is a collection of operations. The operation is defined in the form of a message. The message is defined in the form of an XML architecture. Today, in most people, SOAP and WSDL are quite closely related; they have established basic web service structures along with UDDI. Back to top
Core of the problem
The author of WSDL realizes that XSD play an important role in explaining SOAP messages, so XSD (but they also allow other alternatives). They also realized that some kits have implemented SOAP coding schemes, so it feels necessary to use SOAP encoding. The solution they propose is to define messages based on the XML architecture structure, and then, if needed, allowing the SOAP encoding to use to these messages.
Binding Defining Users need to know some specific details when calling actions defined by a porttype. (This is not a new concept. For example, the COM class is often disclosed by vTable binding and IDispatch binding. Similarly, a method of providing CORBA classes can also be provided by static STUB or dynamic call interface.) Creating a WSDL binding of a porttype's operation to the WSDL binding of the SOAP message sent via HTTP, you must indicate the instance of the schema structure used by the portType included in the SOAP message or encoded. If you select "Text", it means that the XML schema structure referenced by the WSDL definition is the specific specification of the content that will be displayed in the SOAP message body. If you select Code Form, it means that the XML schema structure referenced by the WSDL definition is the abstract specification of the content that will be displayed in the body of the SOAP message; these abstract specifications can be made into specific specifications. (WSDL specification also allows other coding schemes, but these alternatives are very rare even if they have been used.)
This will reveal the core of the problem. As I explained earlier, the SOAP coding scheme seizes the SOAP data model to XML. The SOAP data model represents information in a non-type configuration diagram, and the XML architecture represents information by type of element tree, so how can the SOAP data model encoding scheme definitions of an abstract XML architecture? However, the SOAP specification (defined for SOAP coding) and WSDL specification (using SOAP encoding apply to XML architectural definition) have not answered this issue. In fact, there is no specification to explain what is meant and how to implement it. And this is the problem.
Back to top
Specific example
So far, my argument has always been very theoretical, and now let me give an example to be described more practical. Consider the following for a pseudo code called a Distance operation, the code is used to measure the distance between the two points.
Class Point
{
Public Point () {}
Public Point (int X, int y) {this.x = x; this.y = y;
Public int x;
Public int y;
}
FLOAT DISTANCE (Point P1, Point P2) {
??? ... // apply the pythagorean theorem
}
The following is a WSDL document that describes a porttype called Geometry, which contains a Distance action. It also defines a binding for Geometry PortType, which uses SOAP encoding.
XMLns: wsdl = "http://schemas.xmlsoap.org/wsdl/" XMLns: xsd = "http://www.w3.org/2001/xmlschema" XMLns: soap = "http://schemas.xmlsoap.org/wsdl/soap/" XMLns: TNS = "http://www.gotdotnet.com/team/tewald/sample" Targetnamespace = "http://www.gotdotnet.com/team/tewald/sample"> "http://www.gotdotnet.com/team/tewald/sample">
Uses soap encoding -> Transport = "http://schemas.xmlsoap.org/soap/http" Namespace = "http://www.gotdotnet/team/tewald/sample" Use = "encoded" /> Namespace = "http://www.gotdotnet/team/tewald/sample" Use = "encoded" /> Suppose you want to implement a service that is open to this porttype and binding. Want your implementation checks if its message received from the client matches the format specified by WSDL. If you do not match, you can discard these messages and return an error without any other operations. So, what is the correct message consists of? Consider such a situation, the client passes two different Point instances to the DISTANCE operation, as shown below: Point One = New Point (10, 20); Point TWO = New Point (100, 200); Float f = proxy.distance (one, two); The following is a serialized request message of the client. "http://schemas.xmlsoap.org/soap/envelop/">> "http://schemas.xmlsoap.org/soap/encoding/"> "http://www.gotdotnet.com/team/tewald/sample"> It seems that it is clear that P1 and P2 (specified as NS: distance) These two instances match the architecture definition of the Point type in the WSDL document. They each have a sequence with two elements (X and Y), and the values of these two elements are integers. But this conclusion did not have a sufficient basis. Although the SOAP data model uses an XML architecture simple type (for example, XSD: int) to illustrate a single value (for example, X and Y), it does not use the XML architecture complex type to explain structured data (forced because of this, so I said The SOAP data model is based on non-type structures). If the SOAP data model does not use the XML architecture complex type, SOAP encoding is based on the SOAP data model. Then, the next conference says that P1 and P2 are instances of SOAP encoding of complex type Point, which is it a wise? You may think that I am a problem - after all, P1 and P2 look like Point. Then consider such a situation, the client passes the same Point instance as these two parameters when calling the discance operation, as shown below: Point One = New Point (10, 20); Float f = proxy.distance (one, one); The following is a serialized request message of the client. In this case, the client uses the SOAP coding scheme as a "multi-reference accessor", that is, a single Point Instance (One) is referenced to the two parameters (P1 and P2) of DISTANCE. "http://schemas.xmlsoap.org/soap/envelop/">> "http://schemas.xmlsoap.org/soap/encoding/"> "http://www.gotdotnet.com/team/tewald/sample"> XMLns: ns = "http://www.gotdot.com/team/tewald/sample"> In this case, it is clear that P1 and P2 do not match the architecture definition of the POINT type. In fact, they differ far. They each have an undefined HREF attribute without having the necessary sub-elements x and y. The definition of the input message of the discality operation indicates that P1 and P2 are all instances of Point, but it is clear that in front of SOAP encoding, some cases are not. So what will the result? Elements P1 and P2 sometimes look like Point's semicredient examples, sometimes unlike. In theory, the SOAP coding scheme should tell us what P1 and P2 should look like, unless the method is not determined to apply the SOAP coding scheme to the type specified by the XML schema (for example, POINT). If such a certain method is lacking, it is difficult to implement such a server-public Geometry PortType and binding and make sure all messages received by the server are correct. Back to top Solve code issues Currently, you may think that this is not your problem, because you are not to implement web services from your head. Instead, you use the Web Services Kit and rely on it to handle these details for you. But this does not solve this problem; just push the problem from himself to the toolkit realist, they must try to figure out what should I do. So far, they are not bad in providing support for SOAP coding (although there is still the problem mentioned earlier), the cost is high. Most tool packs use different code paths for text and encoded bindings; from essentially, it is to implement two encapsulating layers, one for text binding, and another binding for encoding. Developers who have time consuming to solve this problem generally think they need a better solution. From a certain point of view, we must adjust the SOAP encoding and XML architecture. Fortunately, we have a very straightforward solution. The SOAP coding rule defines the conversion of the SOAP data model to the XML message. There is no significance of applying the SOAP encoding to the XML architecture because there is no certain relationship between the two. But if a schema is written to illustrate the XML message generated by SOAP encoding, what is the result? The following is a WSDL definition after GEOMETRY PortType, which uses this method. XMLns: wsdl = "http://schemas.xmlsoap.org/wsdl/" XMLns: xsd = "http://www.w3.org/2001/xmlschema" XMLns: soap = "http://schemas.xmlsoap.org/wsdl/soap/" XMLns: TNS = "http://www.gotdotnet.com/team/tewald/sample" Targetnamespace = "http://www.gotdotnet.com/team/tewald/sample"> "http://www.gotdotnet.com/team/tewald/sample">
Note Use Optional Attributes and Element content -> TYPE = "xsd: id" use = "optional" /> TYPE = "xsd: anyuri" use = "optional" />
Uses soap encoding -> Transport = "http://schemas.xmlsoap.org/soap/http" Namespace = "http://www.gotdotnet/team/tewald/sample" Use = "literal" /> Namespace = "http://www.gotdotnet/team/tewald/sample" use = "limited" /> The definition of the Point type update includes declarations for two new attribute IDs and HREFs, as in the element content of this type, both of which are optional. These changes made to Point allow using examples (equivalent to those instances generated by SOAP encoding) when serializing multi-reference data. A Point instance can include an ID attribute with the X and Y child elements, or contain an HREF property, but without child elements. The former represents an example of Point; and the latter represents a reference to Point. Because the XML architecture definition has been equivalent to SOAP encoding operation, it is not necessary to apply coding rules to it, so the binding of Geometry PortType has been updated to use text schema type (EncodingStyle property has been deleted), eliminating about DISTANCE operations The parameters P1 and P2 are any polyses of the instance of Point. Is this method still used SOAP coding? It depends on what you look at. It basically performs the same operation as SOAP encoding, but does not attempt to apply SOAP coding rules to the architecture (this direct application is not good). The key is that the XML architecture contained in WSDL accurately illustrates the message required for PortType and binding. In this way, it is necessary to implement a service that checks the message correct before processing the messages. To make this approach, we need to take several steps. First, we need to define some standard global properties to represent references to nodes in the serialization map. In my example, I define the local ID and HREF attributes as part of the POINT type. This method of this method is that each type of possible use in the sequence graph must define an equivalent attribute using the exact same semantic. Worse, the tool will have to assume that any type with ID and HREF properties is planned to illustrate one picture. If you create some global properties and define some types of references these properties, we do not have to define their properties for each type, and the kit will only identify a pair of properties. (As part of its efforts to help solve the interoperability of Web services, WS-I Basic Overview Working Group has completed some work, but these work has not been disclosed when writing this article.) The toolkit implementation can use these properties as long as there is a standard global property. Basically, they have to make two modifications. First, they must update their WSDL tools to generate and use an XML architecture that contains any type of reference properties that may be used to represent the sequence graph node. They must then update their runtime pipes to use the XML messages that can be used to use these attributes. Back to top future Many people who include myself believe that the waste of SOAP coding is inevitable. W3C XML Protocol Working Group About SOAP 1.2 specification The current draft of SOAP encoding changes into an option (that is, the toolkit can declare SOAP 1.2 compliance without supporting SOAP coding), WS-I Basic Summary Working Group The current draft of its interoperability guide is not allowed to use SOAP encoding in SOAP 1.1, and W3C Web Service Description Working Group selects no support coding in its WSDL 1.2 specification. These changes are reflected in the toolkit to take a while, first we must determine a process-friendly approach to serialize the graph. The toolkit must then be updated. This will take some time, but this waiting is worth it. Finally, the implementation and use of the web service stack will be much simpler.
