| Behind the Web services technology are several protocols: XML, XML Namespaces, XML Schema, SOAP, and WSDL. Some of these are formal W3C industry standards. Some, like WSDL, are just gaining widespread use without yet being codified in a standard. XML XML is a W3C industry standard [1] that provides a way to structure documents to provide relationships between the basic elements of the document. Elements can also have descriptive information called attributes . Elements can be composed of other elements, so they can have complex structure. Since such documents can be represented as text, [2] XML can provide a platform-neutral way to represent data that is transmitted over a network. In particular, as text it can go safely out through a firewall because HTTP port 80 will invariably be open. Here is an example of an XML document that describes a CustomerList composed of several customers. [1] Technically, W3C final documents are called recommendations. However, we will refer to them as standards or specifications. W3C documents that have not reached recommendation status are referred to by their W3C names : proposed recommendations, candidate recommendations, last call working drafts, working drafts, and notes. [2] But they do not have to be text. You can build programs using the abstractions defined in the W3C proposed recommendation Information Set. Using these abstractions, such as document, namespace, element, character , and attribute , to represent the hierarchy of an XML document, you are independent of the particular format in which the XML is stored. Mobile solutions will probably use a more efficient binary format for XML encoding rather than text. The XML Schema Recommendation is written based on the Infoset, not the angle- bracket syntax. The Information Set assumes the existence of XML namespaces. <CustomerList> <Customer> <FirstName>John</FirstName> <LastName>Smith</LastName> <EmailAddress>smith@smith.org</EmailAddress> </Customer> <Customer> <FirstName>Mary</FirstName> <LastName>Jones</LastName> <EmailAddress>mary@jones.org</EmailAddress> </Customer> </CustomerList> XML Namespaces A set of elements and attributes in an XML document can be referred to as a vocabulary. This is particularly useful if this vocabulary can model information that might be reused. For example, we could have vocabularies for financial or chemical information. Namespaces not only allow these vocabularies to be uniquely named in order to prevent conflicts, but allow them to be reused. The following example XML document uses a namespace attribute to uniquely identify the elements <FirstName>, <LastName>, and <EmailAddress> from any other definitions that might use the same tag names with a different meaning or context. The example also shows that abbreviations can be used with namespaces. This is very convenient if multiple namespaces are used in a document. <Customer xmlns:c= "urn:uuid 28833F1C-CBE4-4042-9B35-BF641DFB35DC"> <c:FirstName>John</c:FirstName> <c:LastName>Smith</c:LastName> <c:EmailAddress>smith@smith.org</c:EmailAddress> </Customer> A Uniform Resource Identifier (URI) is used to identify a particular XML namespace. A URI can either be a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). Both represent a unique name . URLs are the familiar Web site addresses, which are unique because they are given out by a central naming authority. A URN is just a unique string. For example, you could use a URN defined by a GUID [3] such as urn:uuid:28833F1C-CBE4-4042-9B35-BF641DFB35DC . [4] URIs used for namespaces do not have to resolve to any location on the Web. [3] A GUID, or Globally Unique Identifier, is a 128-bit identifier that is guaranteed to be unique. GUIDs are widely used in COM. You can generate your own GUIDs using the tool guidgen .exe (Windows UI) or uuidgen.exe (command-line UI). These tools are in the directory ...\Microsoft Visual Studio.NET\Common7\Tools. [4] GUIDs are used in the examples for simplicity and to reinforce the idea that uniqueness, but not existence, is required for a namespace identifier. In real systems URL-based names are used whether or not the URLs actually exist. XML Schema XML with namespaces, however, does not assign any semantics to the data. The XML Schema Definition (XSD) defines a basic set of data types and the means to define new data types. In other words, an XML Schema can assign meaning to the structure of a document. The schema itself is written in XML. The CustomerList document described previously could be defined by the following schema: <schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:c="http://www.acme.com/Customer" targetNamespace="http://www.acme.com/CustomerList"> <xsd:complexType name="Customer"> <xsd:sequence> <xsd:element name="FirstName" type="xsd:string" /> <xsd:element name="LastName" type="xsd:string" /> <xsd:element name="EmailAddress" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </schema> The targetNamespace element defines the name of the schema being defined. This particular string uses the XSD-defined element string . Using XSD, we can restrict the range of values, specify how often particular instances occur, as well as provide attributes to the elements. The schema itself is written in XML. Both the document and its associated schema can be validated and managed as XML documents. The same document, interpreted by two different schemas, will have two different meanings. SOAP While XML schemas can define the types used by the data, you need a set of conventions to describe how the data and its associated type definitions are transmitted. SOAP, the Simple Object Access Protocol, uses XML as a wire protocol to do just this. While SOAP can use XML Schema types to describe the transmitted types, it was designed before the XML Schema specification was finished, so there are some divergences between the two. The reason is that XML Schema describes a hierarchy or tree structure. SOAP wants to be able to represent objects, and objects can have far more complicated relationships than a hierarchy. Classes, for example, can have multiple parent classes. As we will discuss later, this has some implications for Web services. The W3C is currently working on reconciling SOAP with XML Schema. SOAP 1.1 can be used with several transport protocols, not just HTTP. The use of SOAP for Web services on Microsoft platforms is not unique to .NET. Microsoft has released the SOAP Toolkit that has allowed Windows-based platforms to develop Web services. The support for SOAP, however, is built into .NET. The SOAP Toolkit does contain, however, the SOAP Trace Utility, which is useful for tracking raw and formatted SOAP messages. WSDL Objects contain both state and behavior. Schemas define the data. WSDL, the Web Services Description Language, defines the methods and the data associated with a Web service. As the simple example we shall describe shortly demonstrates , WSDL is not necessary for writing Web services. It is important, however, if you want to be able to automatically generate classes that can call Web services or to do anything that requires automatic machine intervention with Web services. [5] Otherwise, you would have to craft and send the SOAP messages by hand. [5] This is similar to VB 6's use of type libraries to make COM programming simpler. Of course, WSDL is a complete description of the Web service, unlike a type library's incomplete description of a COM object and interfaces. As you will see in the following example, the SOAP that is used to describe the Web service's transport format is defined in the WSDL. WSDL is a W3C note.  | 
