Develop Web Services, Part 1: Soap interoperability

 

From

Http://www-128.ibm.com/developerworks/cn/webservices/ws-intwsdl/part3/index.html

Develop Web Services, Part 1: Soap interoperability

Level: elementary

Bilal Siddiqui, CEO, WAP monster

September 01, 2002

In this article, Bilal will start from discussing the development of soap, show you some major soap interoperability problems and their details, and provide an outline of developing Web Services with better interoperability. Bilal also describes how to use the data types in soap.

This is the third article in a series composed of four articles (see references). This series of articles aims to introduce the process of creating, describing, and publishing Web Services. In the first part, I used the WSDL compilation example to explain how to describe a web service. In the second part, I discussed the architecture and semantics of soap. In this article, I will take a look at the soap-related interoperability issues.

The Web service model divides the entire B2B domain into three steps or three domains: Describe a service, bind the service with the specific implementation, and then publish the service through the registration center. These three steps are independent of each other and lead to interoperability issues.

WSDL (Web Service Description Language) constitutes a description domain. Soap overwrites the bound domain and provides unified description, discovery, and integration (Universal Description, discovery and integration, UDDI) the Registration Center covers the publishing domain. My discussions in this section will be limited to interoperability issues related to the bound domain. I will start with discussing the development of soap and discuss the actual soap interoperability issues.

SoapVersion Development

In 1999, when the XML schema specification was still developing and considered a key part of the SOAP specification, W3C began its work on the SOAP specification. Soap uses the XML schema data type definition to define and instantiate the Data Type in soap.

In December May 2000, soap 1.1 was released as W3C minutes (references ). This is the result of the joint efforts of developers from Microsoft, IBM, Lotus Development, and userland software, Inc. Soap 1.1 uses an XML schema working draft with a 1999 namespace URI ("http://www.w3.org/1999/XMLSchema. At present, soap 1.2 (reference materials) is very close to becoming a candidate recommendation, and it has adopted XML schema recommendation (May 2001) and the 2001 namespace URI ("http://www.w3.org/2001/XMLSchema") of the XML schema ").

Interoperability problems

I will start with the soap interoperability problem based on transmission (HTTP.

1.Transmission

The soap 1.1 Specification allows sending soap messages in HTTP requests. As described in section 1 (references), integration of soap and HTTP does not affect the semantics of soap. The SOAP specification will be requiredSOAPActionHeader to the HTTP request header. I have already described in the previous article,SOAPActionThere are three valid values for the header:

• It can be empty

• It can be an empty string enclosed in quotation marks.

• It can also be an arbitrary URI

This flexibility allows soap implementations to choose their ownSOAPActionStyle and its functions. However, this flexibility has led to interoperability issues.

To study these interoperability problems, I created a soap client (reference) that sends a request to the SOAP server (specified by the URL parameter) and displays the server response when receiving the request. After changing the value of the soapaction header, I send simple SOAP requests to different servers to see how the server supports the three headers allowed by the soap 1.1 specification.

DivisionSOAPActionIn addition to the header (this header is operated by me), all my tests are performed according to soapbuilders's 2nd round (basic) echostring test (soapbuilders 'round 2 (base) echostring test) (references. You should visit the 2nd test site of soapbuilders to obtain the WSDL file (basic test), which describes the test web service that will be called during the test.

	TestedSoapServer I tested the following SOAP servers in this article: Apache axis SOAP server Apache SOAP 2.2 Server Whitemesa 2.7 SOAP server Iona xmlbus Soap: Lite Easysoap ++ 4s4c Microsoft ASP. NET Web Services

I used four SOAP requests in the test.

• Listing 1 containsSOAPActionThe header value is a SOAP request enclosed in double quotation marks.SOAPActionThe header value and the value specified in the WSDL file ("Http://soapinterop.org /".

• Listing 2 contains the sameSOAPActionHeader value, but no double quotation marks (Http://soapinterop.org/).

• Listing 3 contains a header different from the one given in the WSDL FileSOAPActionHeader ("Http://differentfromwsdl.org /").

• Listing 4 isSOAPActionThe header specifies a null value.

I sent Listing 1 to whitemesa SOAP server 2.7, which made a successful response, indicating that whitemesa can successfully process suchSOAPActionHeader. Next, I sent Listing 2 to whitemesa and it successfully processed it again. Finally, when ISOAPActionThe value of the header is changed"Http://differentfromwsdl.org /"(Listing 3) whitemesa fails to process the request and returns a fault response. The fault string is"Unrecognized 'soapaction' HTTP header already ed .". Whitemesa SOAP server 2.7 also targets the requests in Listing 4 (whereSOAPActionIf the value is null, a fault response is returned.

I also tested Listing 1, 3, and 4 with Iona xmlbus and soap: Lite, which successfully processed the requests in Listing 1, however, a fault message is returned for the list and request. Iona xmlbus also returns a fault response for Listing 2 (URI is caused without double quotation marks), indicating that it expectsSOAPActionHeader andSOAPActionAnd must be enclosed in double quotation marks. 34

Next, I will send the request in Listing 1, 3, and 4 to easy soap ++ 0.6, which returns the correct response. No matterSOAPActionThe value of the header. Apache axis and Apache SOAP 2.2 Both return the correct response.

Conclusion
To maximize interoperability, we recommend that you use quotation marksSOAPActionThe header value should be included; this value should be consistent with the value given in the WSDL file.

2. xml

XML Schema
This section describes the behavior of various soap servers for different XML Schema versions used during the compilation of SOAP requests. I will analyze the test results of using the test client to test the XML schema namespace Uris supported by different soap servers.

Listing 1 and Listing 5 are identical SOAP requests, except that the XML schema version used is different. Listing 1 uses the 2001 XML Schema Uri, while listing 5 uses the 1999 Uri. I tested the namespace URI support of a large number of servers and found that Iona xmlbus could not successfully process the 1999 Uri, but returned a successful response to the request in Listing 1 using the 2001 Uri. Therefore, the Iona xmlbus support is limited to 2001 XML Schema namespace URI.

I can safely say that 2001 uri Will work for most implementations, but older implementations such as IBM soap toolkit and Apache SOAP still exist widely, using 1999 Uri. Apache SOAP 2.2 receives both 1999 Uris and 2001 Uris, but it uses 1999 URI by default in response messages (although it does allow you to change it to 2001 ). Therefore, you can expect that clients that only expect 2001 Uris (such as Iona xmlbus) will have interoperability problems with earlier soap implementations.

Conclusion
Because 2001 URI will soon become a standard (soap 1.2 specification), and it is widely supported by the current SOAP implementation, for the XML schema namespace URI, the best practice may be to use the 2001 URI in the request.

Connection Type correlation andWSDLAwareness comparison Soap 1.1 allows you to provide information about the types of data contained in messages. This is a text description of the data (for example,int,string). Some implementations rely on this information to correctly deserialize data in messages. Apache SOAP 2.2 is one of the implementations that require explicit input information during connection (that is, data type information is provided as a property value of an element containing data ); otherwise, the data cannot be deserialized. I have discussed the semantics of the WSDL file in Part 1 (references. The WSDL file is used to describe the web service. It contains information about methods published by web services and their descriptions. Because the WSDL file contains information about which parameters can be passed to a method and what content is expected to be returned, this information can be used to deserialize the SOAP request of a method and its response. Therefore, the WSDL file awareness is the solution to the preceding problem. That is, when deserializing a SOAP message, the application can use the data type information provided in the WSDL file. Currently, most implementations are known in WSDL and do not depend on the type of the connection. Apache axis can process data without the need to be typed during connection, and white Mesa 2.7 can also be used. However, there is an interoperability problem here. If the element name is different from the one specified in the WSDL file, white Mesa 2.7 cannot process this request. This is true for many other implementations. On the other hand, Apache axis can handle such a request without issuing a fault. Therefore, if you write such a request for Apache axis, it will not run on white Mesa 2.7. It may be better to write requests and responses that follow the WSDL file for the service. This will be able to process all implementations with WSDL awareness.

3. Data Type

Data Type compatibility may be the most important issue in soap interoperability. If two applications cannot understand each other's data types, they cannot perform meaningful data exchanges and therefore cannot interoperate.

I have already introduced data types in the second article in this series. I have discussed several simple data types and complex data types in that article. Soap uses the XML schema data type and structure to identify the data types carried in the SOAP message.

Data transmitted using soap is first serialized; that is, data values are converted into strings for transmission in XML documents. In the destination, the string must be deserialized, that is, converted to the data type that represents the original value.

It is the responsibility of soap to map the XML schema data type to the appropriate local data type. If the two local data types are inconsistent, that is, the same data type in XML has different values in different implementations (so it has different meanings), then the problem may occur. It is important to maintain data consistency after serialization and deserialization. I will discuss this issue in detail.

Float(Floating point)
AndfloatThe common problems related to this problem occur in the expression of infinity. XML Schema stringINFIndicates infinity. Listing 6 in the requestINFAsfloatSending without limit, Apache SOAP 2.2 server usesInfinityReturns it, while Apache axis returnsINF(List 7 ).

I also tested the MS soap Toolkit 3.0 server by sending the SOAP request in Listing 6. It returns a server-side failure code and cannotfloatInfinity ValueINFDeserialization is like a fault stringSoapmapper: converting data for soapmapper failed inside the typemapper"As pointed out.

Another problemfloatPrecision support. I use 1.23456789e38floatSent to several soap servers (see figure 8 ). Iona xmlbus returns 1.23456789e38, white Mesa 2.7 server returns 1.234568e38, and MS soap Toolkit 3.0 server returns 1.23456786010967e + 38. Although this points out the fact that each implementation is performing interoperability, these implementations still cannot regenerate data into its original value.

Decimal(Decimal)
FordecimalThe XML schema specification requires that the minimum number of digits to be supported is 18 bits. Since there is no limit defined in the Specification, you can set their own limits for each implementation. Microsoft ASP. NET web services and whitemesa 2.7 provide a precision of up to 28 BITs, while Apache axis supports hundreds of bits. This difference in support means that when an Apache axis implementation sends some 28-bitdecimalThe extra precision is truncated, resulting in inconsistent data.

In List 9decimalDigital request (this request carries a largedecimalNumber) to understand the precision support of different servers. In the list, And, you can see responses from the ASP. NET Server, Apache axis, and whitemesa 2.7 respectively. The 4s4c server returns 1.235 in the response to listing 9. 101112

Datetime(Date and Time)
The data type used for time and date information in XML schema isdateTime. White Mesa 2.7 is accurate to seconds. Apache SOAP 2.2 and Apache axisjava.util.DateClass indicates a specific time instance with the precision of millisecond. Use Microsoft ASP. NET Web ServicesDateType, which can indicate the time when the precision is nanoseconds.

Now, if a. Net-based soap client is implemented to soap 2.2 or white Mesa 2.7dateTimeInformation,dateTimeWill be lost, resulting in data inconsistency. Note: In XML schema, the second precision is mandatory, while the second decimal part is optional and valid.

I used the request in listing 13dateTimeTest. The responses from Microsoft ASP. NET web services, Apache axis, whitemesa 2.7, and soap: Lite are displayed in the list, and. 14151617

Byte array (Byte array)
SOAP allows you to exchange data in byte arrays. The byte array must beBase64Encoding. Many implementations failed to pass the soapbuilder (references) in the 2nd round (basic) interoperability testechoBase64Test. Due to the difference in the Data Type format of the Local Machine, some implementations return inconsistent values. Some implementations return values by further encoding the base64 encoded values.

Listing 18 (using 1999 XML Schemabase64BinaryData Type) and listing 19 (using schema 2001base64BinaryData Type) to send a simpleechoBase64Method call.

Apache SOAP 2.2 returns a fault message in both the response in listing 18 and listing 19. The server failed to identify the data types in the two examples, so it was unable to deserialize the Base 64-encoded byte array.

Take a look at listing 20, which specifiesbase64Data Type encoding. Thebase64BinaryCompared to the data type,base64Encoding is defined by the soap 1.1 specification. Apache SOAP 2.2 successfully processes the request in listing 20.

Iona xmlbus successfully handled 19, but handled 18 (Please review the section about the XML schema problem. In that section, I found that Iona xmlbus only supports 2001 XML Schema URI) failed. It cannot identifySOAP-ENC:base64Data Type instance, and then returns a fault string.

From the test above, we can see that when Apache SOAP 2.2 and ionaxmlbus exchange base64 encoded byte arrays, there is a interoperability problem between them.

Array (Array)
Array-based data has always been a difficult test for implementation, especially when the situation is complex and full of nested arrays, multi-dimensional arrays, and nested structures (struct.

structIs a complex, user-defined data type, which can contain simple or more complex data types. Readers with C programming experience may wantstructAnd XML SchemastructMake an analogy between them.

There are several ways to combine one-dimensional arrays and multi-dimensional arrays with other data typesstructs. Therefore, I have designed a large number of SOAP requests to test the behavior of different soap servers. These tests follow the 2nd round (Group B) test suite of soapbuilders. You can obtain the WSDL file for Group B tests on the 2nd web site of soapbuilders.

• Listing 21 contains a simplestringsArray.

• Listing 22 containsstructsArray. The struct containsstring,floatAnd oneintData type.

• Listing 23 contains a two-dimensionalstringsArray.

• Listing 24 defines an offset for a two-dimensional array (This value defines the position from which the array should be processed ).

• Listing 25 containsstruct,structWith a nestedstringsArray.

• Listing 26 contains a two-dimensional array with no size specified in the innermost dimension.

All soap implementations I have tested have no problems with arrays of simple and complex types (I .e., LIST 21 and list 22.

The whitemesa 2.7 server was tested using the following methods: 21, 22, 23, 24, 25, and 26. AlthoughJustWhen the offset (greater than zero) is specified, the whitemesa 2.7 server fails to Process List 25, but it still successfully processes all requests. White Mesa 2.7 shows that the two-dimensional array can be processed when the size of the innermost dimension is not specified (list 26.

I send the request in listing 23 to soap: Lite. Soap: Lite cannot process the request and it returns a string with the fault"Not implemented, because soap: Lite does not generate multidimen1_arrays (yet accepts ;))". Requests in listing 26 can be processed successfully by whitemesa, but cannot be processed successfully by many other implementations. Soap: lite and Apache axis return fault messages.

Conclusion
This includes data exchange for arrays and different combinations of arrays. For most soap implementations, it may be possible, except for the implementations I have mentioned above. To ensure maximum interoperability and data consistency, Web Service developers should write comprehensive data tests consisting of all possible variations of the expected data model, in this way, you can locate the issues that can be solved and confirm the application and data consistency.

Miscellaneous

In soap, there are other places that may cause interoperability problems. These problems may not be handled by the engine.mustUnderstandExpose the SOAP header. You can customize the header to expand the soap function. This scalability also opens a solution channel for proprietary and non-standard solutions that may eventually lead to interoperability problems. SOAP allows multiple response parameters that are not supported by some implementations (such as Apache SOAP 2.2. The encoding mode describes the rules for serializing data to XML and deserializing data from XML. Unfortunately, although soap 1.1 does propose a SOAP message encoding, it does not specify a default encoding for the SOAP message. Soap implementers are not bound by this specification and do not implement the encoding defined by the specification to comply with the specification. Lack of the default encoding mode may cause interoperability problems.

Conclusion

For developers who are planning to build Web services on their current SOAP implementations, or those who are writing their own soap servers and clients, I can provide some suggestions.

1. If you are planning to use soap 1.1 for implementation, encloseSOAPActionHeader, and make sure it is in line withSOAPActionHeaders are consistent.

2. Use the 2001 namespace URI of XML Schema because it is a de facto standard.

3. Follow the encoding defined in soap 1.1 and ensure that the data you send and receive is indeed in the format that it should.

4. The method element name must follow the WSDL description.

5. Provide the data type information for the connection in the SOAP message.

List1. soapactionThe value is"Http://soapinterop.org /"OfSoapRequest.

POST /endpoint HTTP/1.1 Host:host-URL Content-Type: "text/xml"; Charset="utf-8" SOAPAction: "http://soapinterop.org/" <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoString xmlns:ns1="http://soapinterop.org/">             <inputString xsi:type="xsd:string">                 A Test String             </inputString>         </ns1:echoString>     </SOAP-ENV:Body> </SOAP-ENV:Envelope>

List2. soapactionThe value (unquoted) isHttp://soapinterop.org/OfSoapRequest.

POST /endpoint HTTP/1.1 Host:host-URL Content-Type: "text/xml"; Charset="utf-8" SOAPAction: http://soapinterop.org/ <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoString xmlns:ns1="http://soapinterop.org/">             <inputString xsi:type="xsd:string">                 A Test String             </inputString>         </ns1:echoString>     </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Listing 3. SOAP requests whose soapaction value is "http://differentfromwsdl.org.

POST /endpoint HTTP/1.1 Host:host-URL Content-Type: "text/xml"; Charset="utf-8" SOAPAction: "http://differentfromwsdl.org/" <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoString xmlns:ns1="http://soapinterop.org/">             <inputString xsi:type="xsd:string">                 A Test String             </inputString>         </ns1:echoString>     </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Listing 4. SOAP requests with null soapaction values.

POST /endpoint HTTP/1.1 Host:host-URL Content-Type: "text/xml"; Charset="utf-8" SOAPAction: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoString xmlns:ns1="http://soapinterop.org/">             <inputString xsi:type="xsd:string">                 A Test String             </inputString>         </ns1:echoString>     </SOAP-ENV:Body> </SOAP-ENV:Envelope>

List5.WithXML SchemaOf1999NamespaceUriOfSoapRequest.

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/1999/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoString xmlns:ns1="http://soapinterop.org/">             <inputString xsi:type="xsd:string">                 A Test String             </inputString>    </ns1:echoString>     </SOAP-ENV:Body> </SOAP-ENV:Envelope>

List6. "inf"AsFloatInfinitySoapRequest.

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"     xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"     xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"     xmlns:xsd="http://www.w3.org/1999/XMLSchema">     <SOAP-ENV:Body>         <ns1:echoFloat xmlns:ns1="http://soapinterop.org/">             <inputFloat xsi:type="xsd:float">INF</inputFloat>