SOAP Differences

for RuBoard

Before we finish our basic examination of SOAP and WSDL, a more detailed look at the relationship of SOAP, WSDL, and the XML Schema specification is in order. As mentioned earlier, the SOAP encodings used by .NET remoting differ from those used by Web Services and the XML serializer.

To illustrate the differences between the two, we will take the same program and serialize it to disk and use it as a Web Service. The program builds a circular list of two customer items. The two programs are found in the SOAP Differences directory.

The first program, SOAP Formatter , creates a circular list and then serializes it to disk using the .NET SOAP formatter. Although it is superfluous to do so, we derive the Test class from the WebService class to demonstrate that what makes the difference is the way SOAP is serialized, not the basic idea of Web Services.

 using System.Web.Services;  using System;  using System.IO;  using System.Runtime.Serialization.Formatters.Soap;  [Serializable]  public class Customer  {    public string name;    public long   id;    public Customer next;  }  public class Test: WebService  {  static void Main()  {    Test test = new Test();    Customer list = test.GetList();    FileStream s = new FileStream("cust.xml",                                           FileMode.Create);    SoapFormatter f = new SoapFormatter();    f.Serialize(s, list);   s.Close();  }  public Customer GetList()  {    Customer cust1 = new Customer();    cust1.name = "John Smith";    cust1.id = 1;    Customer cust2 = new Customer();    cust2.name = "Mary Smith";    cust2.id = 2;    cust2.next = cust1;    cust1.next = cust2;    return cust1;  } 

This program produces the file cust.xml that has the following SOAP encoding. Note the use of the id attribute to identify objects and fields, and the href attribute that serves as an object reference.

 ...  <SOAP-ENV:Body>  <a1:Customer id="ref-1">  <name id="ref-3">John Smith</name>  <id>1</id>  <next href="#ref-4"/>  </a1:Customer>  <a1:Customer id="ref-4">  <name id="ref-5">Mary Smith</name>  <id>2</id>  <next href="#ref-1"/>  </a1:Customer>  </SOAP-ENV:Body>  ... 

The second version of the program, WebService , as its name suggests, is a Web Service:

 <%@ WebService language="C#" class="Test" %>  using System;  using System.Web;  using System.Web.Services;  public class Customer  {    public string name;    public long   id;    public Customer next;  }   public class Test: WebService  {    [WebMethod]    public Customer GetList()    {      Customer cust1 = new Customer();      cust1.name = "John Smith";      cust1.id = 1;      Customer cust2 = new Customer();      cust2.name = "Mary Smith";      cust2.id = 2;      cust2.next = cust1;      cust1.next = cust2;    return cust1;    }  } 

If you try to run this Web Service from the Internet Explorer using the URL: http://localhost/SOAPWebServiceTest/CustomerList.asmx?op=GetList , ^[12] Internet Explorer will indeed recognize it as a Web Service. See Figure 11-3.

^[12] This URL assumes that you have made the directory SOAP Difference\WebService into a virtual directory with alias SOAPWebServiceTest .

Figure 11-3. Internet Explorer recognizes CustomerList.asmx as a Web Service.

However, if you go on to Invoke the Web Service, you will get the following error:

 System.Exception: There was an error generating the XML     document. --> System.Exception: A circular reference     was detected while serializing an object of type     Customer.   at System.Xml.Serialization.XmlSerializationWriter.     WriteStartElement(String name, String ns, Object o,     Boolean writePrefixed)  ...     at System.Xml.Serialization.XmlSerializer.Serialize      (XmlWriter xmlWriter, Object o,       XmlSerializerNamespaces namespaces)  ... 

The XML Serializer used to produce the SOAP for Web Services cannot handle the circular reference. If you comment out the line of code: cust2.next = cust1 , the Web Service will be able to respond with:

 ...    <name>John Smith</name>    <id>1</id>    <next>      <name>Mary Smith</name>      <id>2</id>      <next xsi:nil="true" />    </next>  ... 

There is no notion, however, of any real relationship between the items, as there was in the remoting case. Why can the SOAP in .NET remoting handle the relationships while the SOAP in Web Services cannot?

SOAP handles the complicated relationships (multiple parents, graphs, etc.) that exist in an object model. XML Schema still reflects the XML heritage of document processing where you can model a document as a tree with a single root, each node having one parent. Since SOAP was being developed before XML Schema was finished, SOAP has some extensions to handle those cases. Since they are in Section 5 of the SOAP specification, they are often referred to as the Section 5 encoding rules.

Those parts of the Section 5 encoding rules that are extensions cannot be incorporated in any XML document that has to be validated against a schema. Hence, the .NET XML serialization classes do not use them. On the other hand, the .NET remoting serializer does not care about schema validation; it cares about the ability to remote full object fidelity and hence uses all the Section 5 rules. In order to maximize interoperability, Web Services implementations tend to use only XML Schema compliant forms that can be validated against a schema. ^[13] The counterargument can be made that schema validation is not as important when machines are generating the XML, but the industry has not yet taken that approach. ^[14]

^[13] Although we will not discuss them here, there are attributes you can set on your Web Service class and methods to have them use the Section 5 rules.

^[14] There is no intent here to slight the security issues associated with Web Services, but if you cannot get the object models to work together in some fashion, security becomes irrelevant because there is nothing to make secure.

If you want applications and Web Services that reside on different operating system platforms to interoperate , define your Web Services with XML Schema first, then develop the associated WSDL. You can then create an abstract class that can be the basis for an .asmx file by using the /server option on the Wsdl tool.

Starting with an object model and then modeling it with XML Schema might result in incompatible systems. Of course, if only simple types and structures are involved, you are not going to have problems. If you have existing object models, you may need a wrapper layer that translates the Web Services layer and moves it into your existing object model. This is the major technological challenge of Web Services ”getting the object models on different platforms to work together. ^[15]

^[15] If you have a COM background, think of the work the proxy has to do to handle pointer aliasing if the pointer_default(unique) attribute is not used.

for RuBoard