Tutorials to .com

Tutorials to .com » Dotnet » Webservice » Web Services Interoperability and SOAP

Web Services Interoperability and SOAP

Print View , by: iSee ,Total views: 7 ,Word Count: 2510 ,Date: Wed, 20 May 2009 Time: 8:32 AM

Abstract: This paper outlines the adoption of SOAP for RPC call when the actual existence of the current interoperability problems, also discussed the issue of interoperability led to three factors: HTTP problem, xml and SOAP intermittent.

Contents

Introduction What is SOAP?
Interoperability issues common transmission problem
xml problem
Follow-up SOAP topic

Introduction Currently, there are a variety of platforms to create applications. However, the use of each platform are accustomed to their own agreements (in essence is usually binary code) to achieve integration between machines. Therefore, cross-platform data sharing application is very limited capacity. Recognizing that these restrictions, people have been committed to the establishment of the data formats and data exchange standards, to take this in order to achieve "No matter which software services, what hardware will be able to straddle the boundaries of the traditional to Web - forms seamlessly integrated with them, "the long-term objectives. At present, the rapid development of this objective has become a new paradigm of computing.

The target is the core of the concept of interoperability, that is, different systems can communicate seamlessly and share data. This is also the goal of Web services. Web services is a standard Internet protocol used to access the application of the programmable logic; from another point of view, Web services are inter-related machinery and transparent communication between applications, and through the use of Web standards to achieve specific.

At present, the realization of inter-machine messaging a variety of Web services technology, such as Simple Object Access Protocol (Simple Object Access Protocol,
SOAP), Web Service Description Language (Web Service Description Language, WSDL) and hypertext transfer protocol (HyperText Transfer
Protocol, HTTP). The complexity of these messages are different, both a simple method call, but also the complexity of the orders submitted. In Web services functions,
Higher but the most general function is to achieve the RPC (Remote Procedure Call) forms of communication (through RPC, a computer program on another computer can perform the procedure.) This article from the practical point of view, introduced for the use of SOAP RPC current forms of communication common interoperability problems, since the author will explore the adoption of SOAP, WSDL and other agreements the issue of transmission of information.


Figure 1: Web services road map: Cable agreement element, service description and discovery

What is SOAP?
SOAP is the Simple Object Access Protocol (Simple Object Access Protocol) abbreviation. The agreement of the current version is 1.1, the specific norms issued in the following site: www.w3.org/tr/soap (in English). SOAP to XML-based, describes the inter-machine messaging communications format. In addition, it also includes several optional parts, used to describe the method call (RPC) and the detailed description of SOAP message sent through the HTTP method. (SOAP and Web services on the detailed background, see the Web services platform (in English).)

The following is a typical SOAP request (including HTTP headers), which is named the request of the RPC method call EchoString, and a string as a parameter:

POST / test / simple.asmx HTTP/1.1
Host: 131.107.72.13
Content-Type: text / xml; charset = utf-8
Content-Length: length
SOAPAction: "http://soapinterop.org/echoString"

<? xml version = "1.0" encoding = "utf-8"?>
<soap: Envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns = "http://soapinterop.org/" xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoString>
<inputString> string </ inputString>
</ tns: echoString>
</ soap: Body>
</ soap: Envelope>

As indicated above, the request for the method of encoding XML: <tns:echoString>, will be encoded as a string parameter <inputString>. It represents the c # method is similar to the following:

public String echoString (String inputString);

The following is a response from the server:

HTTP/1.1 200 OK
Content-Type: text / xml; charset = utf-8
Content-Length: length

<? xml version = "1.0" encoding = "utf-8"?>
<soap: Envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns = "http://soapinterop.org/" xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return> String </ Return>
</ tns: echoStringResponse>
</ soap: Body>
</ soap: Envelope>

Of the sequence of string data type and shape the rules of method calls in SOAP 1.1 section 5 and section 7 (www.w3.org/tr/soap (English))
Defined.

Common interoperability problems when the implementation of RPC form of SOAP messaging may be due to a variety of reasons led to interoperability problems. It is interesting to note that many interoperability issues are not
SOAP itself, but the basic engine or transmission caused by XML engine interoperability issues. In other words, interoperability issues may be:

HTTP issues


XML, or


SOAP discontinuity should also be noted that the formulation of these norms are also ill-considered places, they sometimes may be ambiguous, so it is difficult to determine the only correct behavior.

Transmission problem
XML Web services is the core message of the transport mechanism to send messages. When the adoption of SOAP for RPC calls, HTTP is the most commonly used transport mechanism.
This means that the SOAP stack must exist between the HTTP interoperability problems.

HTTP interoperability problem is a simple example of the use of SOAPAction. SOAPAction is an HTTP header, it must exist in the adoption of HTTP
SOAP message transmission. This header can be given to a number of different values, such as:

SOAPAction: "http://tempuri.org/"

Although the value of SOAPAction completely empty, but must use quotation marks:

SOAPAction:

The problem here: If the server requires a null value SOAPAction, some clients will not be able to meet this requirement, because not all HTTP client API has set empty HTTP header values. This problem may be the existence of two solutions: to amend the client API and / or to ensure that the server does not require null value
SOAPAction. Typically, to avoid such problems is the only way to ensure that the HTTP API stability strong, and known to work in the Web. Even so, these problems may still arise; to the total elimination of them, the test may be the only way.

XML is a problem that may exist in this second category of interoperability issues, which relate to parsing XML and XSD architecture. SOAP and XML framework for the use of XML as a core, so that interoperability between the two is the basis of SOAP interoperability.

There is an interesting example of the interoperability problem, it relates to XML parsing and HTTP transmission, and with the byte order marker (Byte Order Mark,
BOM) related. When sending data through HTTP, you can Content-Type header specified in the form of data encoding such as UTF-16 or UTF-8. You can also insert a set of code used to specify the form of a byte to indicate the form of a section of XML code. When to send UTF-16, even if the Content-Type header to specify the encoding format, it still needs to indicate BOM is big-endian or little-endian; but UTF-8, BOM is unnecessary. For example:

HTTP/1.1 200 OK
Content-Type: text / xml; charset = utf-8
Content-Length: length

n + + <? xml version = "1.0" encoding = "utf-8"?>
<soap: Envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns = "http://soapinterop.org/" xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return> String </ Return>
</ tns: echoStringResponse>
</ soap: Body>
</ soap: Envelope>

Examples of the first three characters in the byte order mark is hex code for the form of instructions encoded UTF-8, however, you can see, Content-Type also pointed out that this point. Even if not required, but some programs will achieve the UTF-8 sent to BOM. With the realization of the program while others can not deal with BOM but XML. To address this issue, should be avoided when not required to send in the BOM, and should correctly handle the BOM. Because UTF-16 in dealing with the needs of news BOM, so in this case must correctly handle the BOM. Although there is no single way to solve these problems early, but the question of when discovered, the best way is to refer to the specific description of the standard specification (usually can be found in the W3C), and then apply these norms to judge the problems encountered.

SOAP now, we will discuss the core of the problem: SOAP problem itself. As mentioned above, SOAP interoperability solution requires, first of all transmission (usually HTTP) and XML
. To solve these two problems, then solve the problem of SOAP.

SOAP itself is relatively simple. It requires the message into an envelope, and information on the actual content of the text elements. SOAP Mark element as a first option, to the body element can contain the contents of a certain degree of flexibility allowed. The following is a simple example of the SOAP message, the majority of the stack with each other when it should not be any problems:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<foo />
</ soap: Body>
</ soap: Envelope>

Although this example is not very interesting, but the SOAP also provides a common data type coding method (see the SOAP specification section 5), which further explains how to encode RPC method call. You may have noticed that in the previous example, the methods are a subset of the body tag, parameter is the method of sub-tags.

Even if no such trouble, you can also find many interesting issues of interoperability. For example, SOAP specification stipulates that if you receive the mustUnderstand attribute set to "1" of the SOAP header, it is necessary to understand it, or they will make mistakes. But many of the realization of the program has not achieved this. The following is an example of mustUnderstand header:

HTTP/1.1 200 OK
Content-Type: text / xml; charset = utf-8
Content-Length: length

n + + <? xml version = "1.0" encoding = "utf-8"?>
<soap: Envelope xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns = "http://soapinterop.org/" xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<Foo SOAP-ENV:mustUnderstand="1">
Hello!
</ Foo>
</ SOAP-ENV: Header>
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<tns:echoStringResponse>
<Return> String </ Return>
</ tns: echoStringResponse>
</ soap: Body>
</ soap: Envelope>

This example is SOAP interoperability testing one of the many problems found. Has been found on the interoperability issues of more examples, see
http://groups.yahoo.com/group/soapbuilders (English) in the file. In short, in order to ensure the realization of RPC in the form of SOAP communication interoperability, SOAP to build the world have done a lot of work, and have achieved fruitful results. From May 8 to May 10, will be held in Las Vegas Networld + Interop Conference, at which time, SOAP will be many members of groups at the meeting in this regard will be fully demonstrated results. If you use the SOAP stack or interested are welcome to patronize the demonstration.

In addition, the XML Web services has been much discussion and testing in http://groups.yahoo.com/group/soapbuilders (English),
http://www.mssoapinterop.org/ (English) and http://www.xmethods.net/ilab/ (English), etc. on the site. These site contains a number of interoperability testing of the link endpoint. SOAP stack to build all the staff should read these files and to participate in interoperability testing.

This paper summarizes the follow-up topic in the area of XML Web services found in a number of interoperability problems early. However, this discussion does not stop there. In addition to
HTTP to RPC call outside, SOAP and many more interesting situation to be discussed. Including the "document" form of message passing, based on the SMTP
And other transmission mechanism SOAP, WSDL and SOAP header various testing - all these are worth in the future to discuss the article.


.Net WebService Articles


Can't Find What You're Looking For?


Rating: Not yet rated

Comments

No comments posted.