XML Classes in the .NET Framework

1. The client creates an instance of the XML Web service proxy class on the same computer on

which the client resides.

2. The client calls a method on the proxy object.

3. The XML Web services infrastructure on the client system serializes the method call and the

arguments to the method into a SOAP request message and sends it to the XML Web service over the network.

4. The infrastructure on the server on which the XML Web service resides deserializes the SOAP

message and creates an instance of the XML Web service. The infrastructure then calls the actual web service method passing in the arguments on the XML Web service.

5. The XML Web service executes the method and returns the value with any output parameters to

the infrastructure.

6. The infrastructure serializes the return value and the output parameters into a SOAP response

message and sends them back to the client over the network.

7. The infrastructure on the client computer deserializes the SOAP response containing the return

value and the output parameters and sends them to the proxy object.

The proxy object sends the return value and the output parameters to the client.

As you can see from the preceding steps, the XML Web Services infrastructure provided by the .NET Framework plays an important role in building, deploying, and consuming Web services. In addition, Visual Studio 2005 provides tools that allow you to easily and effectively build, deploy, and publish your XML Web services using ASP.NET.

XML Classes in the .NET Framework

From the highest level, one can simply define an XML Web service as a unit of code that can be invoked via HTTP requests. Unlike a traditional Web application however, XML Web services are not (necessarily) used to emit HTML back to a browser for display purposes. Rather, an XML Web service exposes the same sort of functionality found in a standard .NET code library, in that it defines computational objects that execute a unit of work for the consumer (such as crunch some numbers, read information from a data source, etc.), return a result (if necessary), and wait for the next request.

XML Web services provide a way for unrelated platforms, operating systems, and programming languages to exchange information in harmony. One important feature of the XML Web services-based computing model is that a client need not know the language in which XML Web services are implemented. The client just needs to know the location of an XML Web service and the methods that the client can call on the service. The only requirement on the client side is that the client should be able to parse a well-formed XML document and then map the underlying XML elements into platform and/or language specific types. In a nutshell, XML Web services offer a way to let the Web provide information that can be pieced together to build a platform and language-agnostic distributed system.

XML Web Ser vices Infrastructure

One of the important features of the XML Web services-based computing model is that both clients and XML Web services are unaware of the implementation details of each other. The XML Web services infrastructure provides several components that enable client applications to locate and consume XML Web services. These components include the following.

XML Web Services Directories

These directories provide a central place to store published information about XML Web services. These directories might also be XML Web services that allow you to search for information about other XML Web services programmatically. The Universal Description, Discovery, and Integration (UDDI) specifications define the guidelines for publishing information about XML Web services. The XML schemas associated with UDDI define four types of information that you must publish to make your XML Web service accessible. This information includes business information, service information, binding information, and service specifications. Microsoft provides its own implementation of UDDI specification, which is located at http://uddi.microsoft.com.

XML Web Services Discovery

Using this process, clients locate the documents that describe an XML Web service using WSDL. The discovery process enables clients to know about the presence of an XML Web service and about the location of a particular XML Web service.

XML Web Services Description

This component provides information that enables you to know which operations to perform on an XML Web service. The XML Web service description is an XML document that specifies the format of messages that an XML Web service can understand. For example, the description document specifies the SOAP message schemas that you use when invoking methods on an XML Web service.

XML Classes in the .NET Framework

You can also use XmlReader classes to determine various factors such as the depth of a node in an XML document, whether the node has attributes, the number of attributes in a node, and the value of an attribute. To perform validation while reading the XML data using the XmlReader class, use the new

System.Xml.XmlReaderSettings class that exposes properties which can be set to appropriate values to validate XML data using DTD and XSD schemas. The XmlReaderSettings class is described in detail in Chapter 5.

Although the .NET Framework includes concrete implementations of the XmlReader class, such as the

XmlTextReader, XmlNodeReader, and the XmlValidatingReader classes, the recommended practice in .NET Framework 2.0 is to create XmlReader instances using the Create() method. The

XmlReader object returned by the Create method has better conformance checking and compliance to the XML 1.0 recommendation.

SAX Vs XmlReader

When you first look at it, the .NET Framework class library’s implementation of forward-only access seems very similar to the Simple API for XML (SAX), but actually they are fundamentally different. Where SAX uses a more complex push model, the class library uses a simple pull model. This means that a developer requests or pulls data one record at a time instead of having to capture the data using event handlers. Coding using the .NET Framework class library’s implementation of forward-only access is more intuitive because you can handle the processing of an XML document as you would a simple file, using a good old-fashioned while loop. There is no need to learn about event handlers or SAX’s complex state machine.

Random Access via DOM

The XML DOM class, System.Xml.XmlDocument, is a representation of the XML document in memory. The .NET Framework DOM implementation provides classes that enable you to navigate through an XML document and obtain relevant information. Every XML document consists of parent and child nodes. The XmlDocument class has the capability to read in XML files, streams, or XmlReader objects. Among the many public methods of the XmlDocument class, you will want to start with the Load()

method. Using this method, you can easily load XML data into an XmlDocument object.

Choosing the Right XML Reader

Basically, you could take an either/or approach when you choose your XML class for reading. For example, either you choose the XmlReader class for fast, forward-only, read-only, non-cached type reading. Or you can choose the DOM class XmlDocument for full-featured XML document reading and manipulation. The major deciding factors for choosing one method over the other are whether all data needs to be in memory at one time (large files take up large amounts of memory, which in many cases isn’t a good thing) and whether random access to the data is needed. When either of these factors is a requirement, the DOM tree should probably be used because the process of repeatedly reading forward sequentially through a docu- ment to find the right place in the stream of XML to read, update, or write random data is time consuming.

Is XML API in .NET a Replacement for MSXML 6.0?

Microsoft’s XML parser, MSXML 6.0 (now known as Microsoft XML Core Services), has historically provided much of the XML DOM support described in this section. The .NET XML managed objects largely overlap the functionality exposed in the COM-based MSXML 6.0 library. Generally, you want to use the managed objects offered in the various .NET XML namespaces. There are occasions, however, when you should use the MSXML 6.0 implementation when you need backward compatibility with

XML Classes in the .NET Framework

In Chapter 3, I take a brisk walk through all the new XML classes in the .NET Framework, which will be
discussed in more detail throughout the rest of the book.
Microsoft has introduced several new applications of XML in .NET 2.0 and has also done some innova-
tive work to improve the core XML API. I start with a discussion on the use of XML in configuration
files, DOM, XSD schema validation, XSLT transformations, XML serialization, Web services, and XML