Professional ASP.NET 1.0 XML with C#
This book concentrates on describing how XML can be effectively used within ASP.NET applications. Coverage includes discussion of where and when to use XML, detailed discussion of the System.XML namespace, ADO.NET as it relates to ASP.NET, SQL Server 2000 and SQLXML managed classes, and XSLT. Furthermore the book specifically spends time highlighting new developments in XML related standards and technologies, and performance issues that the advanced ASP.NET developer should be aware of.
This book is aimed at the experienced web developer who already has a grasp of ASP.NET and a basic familiarity with XML and related technologies. The book is written in C# and aims to augment the skill set of those seeking to progress their .NET experience.
Read Chapter 1: Introduction to XML Technologies from this book
Read Chapter 5: Transformations from this book
Print this article
Buy this book!
Introduction to XML Technologies
In this chapter, we'll look at current and upcoming Extensible Markup Language (XML). We'll begin by describing what XML is and then talk about where it can help us, some related standards, and focus on some important design considerations when writing an XML application.
More specifically, this chapter follows this route map:
By the end of this chapter, you'll have a good understanding of the key XML standards, what they do, where they fit, and how they relate to each other.
An Introduction to XML
The success of XML can be gauged by the fact that since its release in February 1998, there are now more than 450 other standards based on XML or directly relating to XML in some way. A day seldom goes by without our encountering XML somewhere, either in a press release, or white paper, or online/print article. Almost all new (mostly Web) application development jobs post XML experience as a preferred skill to have. Microsoft's .NET Framework represents a paradigm shift to a platform that uses and supports XML extensively. Every database and application vendor is adding some kind of support for XML to their products. The success of XML cannot be overemphasized. No matter which platform, which language you are working with, knowledge of this technology will serve you well.
What is XML?
In its simplest form, the XML specification is a set of guidelines, defined by the World Wide Web Consortium (W3C), for describing structured data in plain text. Like HTML, XML is a markup language based on tags within angled brackets, and is also a subset of SGML (Standard Generalized Markup Language). As with HTML, the textual nature of XML makes the data highly portable and broadly deployable. In addition, XML documents can be created and edited in any standard text editor. But unlike HTML, XML does not have a fixed set of tags; rather it is a meta-language that allows creation of other markup languages. It is this ability to define new tags that makes XML a truly extensible language. Another difference from HTML, which focuses on presentation, is XML's focus on data and its structure. For these reasons, XML is much stricter in its rules of syntax, or "well- formedness", which require all tags to have a corresponding closing tag, not to overlap, and more. For instance, in XML you may define a tag, or more strictly the start of an element, like this, <invoice>, and it could contain the attribute customer="1234" like so: <invoice customer="1234">. This element would have to be completed by a corresponding closing tag </invoice> for the XML to be well-formed and useable.
The W3C is an independent standards body consisting of about 500 members, formed in 1994 under the direction of Tim Berners-Lee. Its primary purpose is to publish standards for technologies directly related to the Web, such as HTML and XML. However, the syntax and usage that the W3C devises do not have governmental backing, and are thus not officially 'standards' as such, hence the W3C's terminology of 'Recommendation'. However, these Recommendations are de facto standards in many industries, due to the impartial nature of the W3C itself. Once a standard has achieved Recommendation status, it will not be modified or added to any further. Before reaching that status, standards are first classed as Working Draft, which is still subject to change, and finally a Last Call Working Draft, where no significant changes are envisaged.
XML Design Goals
There were ten broad goals that the designers of the XML 1.0 specification (http://www.w3.org/TR/REC-xml) set out to achieve:
Overall, the team did a pretty good job of meeting these aims. As plain text, like HTML, XML side- steps many platform-specific issues and is well suited to travel over the Internet. In addition, the support for Unicode makes XML a universal solution for data representation (Design Goal 1).
- XML must be readily usable over the Internet.
- XML must support a wide variety of applications.
- XML must be compatible with SGML.
- It must be easy to write programs that process XML documents.
- The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
- XML documents should be human-readable and reasonably clear.
- The XML specification should be ready quickly.
- The principles of the specification must be formal and concise.
- XML documents must be easy to create.
- Terseness in XML markup is of minimal importance.
It is a common misconception that XML is useful only for Web applications. However, in reality, the application of XML is not restricted to the Web. As XML is architecture-neutral it can easily be incorporated in any application design (Design Goal 2). In this chapter we'll see how and where XML is being used today.
XML is in effect simplified SGML, and if desired can be used with SGML tools for publishing (Design Goal 3). For more information on the additional restrictions that XML places on documents beyond those of SGML, see http://www.w3.org/TR/NOTE-sgml-xml-971215.
Apart from the textual nature of XML, another reason for XML's success is the tools (such as parsers) and the surrounding standards (such as XPath, XSLT), which help in creating and processing XML documents (Design Goal 4).
The notion behind XML was to create a simple, yet extensible, meta markup language, and this was achieved by keeping the optional features to the minimum, and making XML syntax strict (at least, in comparison to HTML) (Design Goal 5).
Prior to XML, various binary formats existed to store data, which required special tools to view and read that data. The textual (if verbose) nature of XML makes it human readable. An XML document can be opened in any text editor and analyzed if required (Design Goal 6).
The simplicity of XML, the high availability of tools and related standards, the separation of the semantics of a document from its presentation, and XML's extensibility all result from meeting Design Goals 7 through 10.
Before looking at XML syntax and XML-related standards, let's first review some of the applications of XML.
The Appeal of XML
The second design goal of the XML specification was that XML's usefulness should not be restricted to the Web, and that it should support a wide variety of applications. Looking at the current situation, there's no doubt that this goal has been very well met.
The Universal Data Exchange Format
When Microsoft announced OLE DB as part of the Windows DNA initiative, everybody started talking about what it was promising, namely Universal Data Access. The underlying concept is that, as long as we have the proper OLE DB provider for the backend, we can access the data using either low-level OLE DB interfaces or by using the high-level ADO object model. The idea of Universal Data Access was very well received on the Microsoft platform, and is still a very successful model for accessing data from any unspecified data store. However, the missing piece was the data exchange. There was no straightforward way to send data from one data-store to the other, over the Internet, or across platforms.
Today, if there is need to transfer data from one platform to the other, the first thing that comes to mind is XML, for the reasons already discussed. If we compare XML as a means of data transfer against the traditional Electronic Data Interchange (EDI), XML wins hands down because of its openness, simplicity, extensibility, and lower implementation cost. This lower cost stems mainly from XML's use of the Internet for data exchange, which is not easily achieved (if not impossible) with EDI, which relies on private networks.
Let's take an example of how XML enables universal data exchange. Consider a company, ABC Corp., that has outsourced some of its technical support to another company, XYZ Corp. Let's assume that there is a need to send support requests from ABC Corp to XYZ Corp, and vice versa, everyday. To add to the soup, the companies are located in different countries, and do not share a network. In addition, ABC Corp. runs SQL Server 2000 on Windows 2000 Advanced Server, while XYZ Corp. runs Oracle 8 on Sun Solaris. As both SQL Server and Oracle support XML, and there are many tools and APIs available to import and export XML, and as XML data can be very easily accessed over HTTP or FTP, the clear choice here would be to exchange the support requests in XML format. The two companies can establish a Schema to define the basic structure of their XML documents, which they then adhere to when sending XML data to each other. We'll discuss Schemas later in the chapter.
Business transactions over the Internet require interoperability while exchanging messages, and integrating applications. XML acts like the glue that allows different systems to work together. It is helping to standardize the business processes and transaction messages (invoices, purchase orders, catalogs, etc.), and also the method by which these messages are transmitted. E-business initiatives such as ebXML, BizTalk, xCBL, and RosettaNet make use of XML and facilitate e-business, supply chain and business-to-business (B2B) integration. XML mainly helps in streamlining the data exchange format.
XML – Industrial Glue
XML is not just well suited for data exchange between companies. Many programming tasks today are all about application integration: web applications integrate multiple Web Services, e-commerce sites integrate legacy inventory and pricing systems, intranet applications integrate existing business applications.
All these applications can be held together by the exchange of XML documents. XML is often an ideal choice, not because someone at Microsoft (or Sun or IBM) likes XML, but because XML, as a text format, can be used with many different communications protocols. Since text has always been ubiquitous in computing, standard representations are well established, and are supported by many different platforms. Thus, XML can be the language that allows your Windows web application to communicate easily with your inventory system running on Linux because both support Internet protocols and both support text. What is more, through the .NET classes for Windows and various Java class libraries for Linux, both support XML.
Data Structures for Business
We're all used to data structures in programs. In theory, these structures model the business objects – the "things" we deal with in our programs – which describe a business and its activities. A retail business may have structures to represent customers; or in manufacturing, structures might model the products that the company makes.
Ideally, these data structures would be idealized representations of the business entities that they model, and their meaning would be independent of the program for which they were originally designed. In practice however, data structures don't faithfully replicate their real-world counterparts, as, through pressures of time or technical limitations, programmers generally employ shortcuts and workarounds in order to make the application work. To deal with a particular problem, programmers all too often opt for the quick and easy solution, adding a little flag here or a small string there. Such quick fixes are commonly found in working systems, which can become encrusted with so many such adornments that they can no longer usefully be exchanged with other programs. They are far removed from the faithful representations of real-world entities that they should be, and they serve merely to keep a specific application going and no more.
This specialization impedes reuse, hindering application-to-application integration. If you have five different representations of a customer throughout your organization, the web site that talks to your legacy applications will have to include a lot of hard-to-maintain code to translate from one object to another. It's important to create structures that promote integration as we go forward.
Making XML vocabularies that represent the core structures of a business is an excellent way to go about this. We can develop a vocabulary for each major object or concept in the business detailed enough for programs to manipulate objects of that type using that vocabulary alone. For example, if we are describing a person outside our organization, we could stop at the name and telephone number. This might serve our current needs, but could cause problems when we develop further applications. It is worth the initial effort to establish a more comprehensive, 'future-proof' representation, such as that represented by the following XML document:
<Name first="Jack" last="Happy" prefix="Mr."/>
<loc:Street1>180 Pershing Blvd</loc:Street1>
<OrgName>Fast Wind Prototypes, Inc.</OrgName>
This brief document is enough to identify the person, communicate with them, and locate them. There are probably other details we could add, depending on the needs of our business.
On a related note, when creating these schemas, it's unwise to do so within the context of a single project team. Get the buy-in of a variety of stakeholders. Preferably, developing the schemas for a business is performed separately to any single programming task. Otherwise, the risk is that the vocabulary will get specialized to a particular application (just as binary formats did), or the schema will lack the support of other groups and the vocabulary will never get adopted. If you are lucky, a standards body associated with your particular market may have already developed schemas suitable for your business, in which case all that development work has already been done for you, not to mention the other potential benefits of adopting an industry standard.
The effort of devising a schema divorces data from application logic, a separation that becomes all the easier to maintain in applications. If the vocabulary is well designed, it will facilitate the creation of database schemas to hold the data, and code components to operate on them, and the code and database schemas will be useful throughout the business. When the time comes to integrate two applications built on one of these schemas, the applications already have a suitable communications medium as both use XML documents conforming to the same schemas.
A word of caution is in order, however. XML is not especially compact and efficient as a storage medium, and you certainly don't want to model every data structure in XML, nor do you necessarily want to use XML documents as your primary data structures in applications. Still, for modeling a large- scale, widely-used business concept, the advantages of XML make it hard to beat.
Integrating data with application logic is simple when there is a single database technology in use. Things get harder when several databases – say Oracle and SQL Server – or a mix of relational and non-relational data are employed. If all the data for a given concept resides in a single data store, life is still simple. It is when the data for a concept is spread across various storage media that there is some integration to perform. For example, employee information might be stored in a relational database in Human Relations and an LDAP directory (an hierarchical store) for the IT department. Putting together an employee's address (from HR) with their e-mail URL (from IT) would require dealing with two disparate structures. Both formats are binary, but one is relational, with a flat sequence of rows. The other is hierarchical, so may contain similar information in a nested format.
If, however, the primary concepts are modeled in XML, integration like this becomes a lot easier. Technologies like XPath and XSLT can be used to splice, insert, or otherwise manipulate data from multiple sources to get the final, integrated result required.
Consider the employee information example again where we need some information from the HR database, while other information must be drawn from the IT directory. We have to merge the two subsets to get the final structure relevant to our needs. If we are dealing with native binary formats, we'll end up writing a lot of special-purpose code. On the other hand, if we convert the results from each source into XML before performing the merge, we can use XPath to retrieve the data for each employee, and the Document Object Model or some other XML-related technology to perform the merging. Better still, many data stores are becoming equipped with native support for XML, so the data store may be able to output the data directly in XML, as depicted in the following figure. Performing initial conversions like this can open up the possibility of using off-the-shelf XML tools to work on the data, greatly reducing the code we have to write.
Separation of Content and Presentation
With HTML, the actual data and its presentation logic are interleaved. HTML tags do not add any semantic meaning to the data content, but just describe the presentation details. This approach makes it hard to manipulate just the data or just the way it is presented. The Cascading Style Sheets (CSS) initiative made an effort to separate data from the presentation, but still many Web pages squirrel data away inside presentation tags.
As XML makes no assumption about how tags might be rendered on the display device (browser, wireless cell phone, PDA, or whatever), but simply provides a means to structure data with tags we define ourselves, it is quite natural to use the same XML data document and present it differently on different devices. This separation of data from presentation also facilitates easy access to the data
Increasing numbers of HTML Web sites now offer an XML interface. For example, Amazon offers an XML interface that allows its associates to build targeted, customized Amazon placements (http://associates.amazon.com/). Google exposes its search engine via a SOAP-based XML interface (http://www.google.com/apis/). Microsoft's MapPoint .NET initiative allows us to integrate maps, driving directions, distance calculations, and proximity searches into our applications. Separating data from presentation is the key allowing developers to build new and innovative applications.
Other W3C standards, such as Extensible Stylesheet Language Formatting Objects (XSL-FO) and Transformations (XSLT), can be used for the formatting and presentation of XML data.
Already, many new markup languages based on XML syntax have been created to meet the needs of specific application domains. The most well known of these have general utility, and include:
(http://www.w3.org/TR/MathML2) enables mathematical equations to be served, received, and processed on the Web.
(Synchronized Multimedia Integration Language, http://www.w3.org/TR/smil20) is an XML-based language for writing interactive multimedia presentations. Using the XML syntax, it allows the mixing of many types of media, text, video, graphics, audio, and vector animations together, synchronizing them to a timeline, for delivery as a presentation over the Web.
(http://www.w3c.org/2002/ws) applies XML syntax to messaging, and is at the core of Web Services. SOAP enables highly distributed applications that can run over the Internet without any firewall issues. Extra layers are being built on top of SOAP to make it more secure and reliable. These layers include WS-Security, WS-Routing, WS-License, and so on, which form part of Microsoft and IBM's Global XML Web Services (GXA) Specification, discussed later in this chapter.
(Scalable Vector Graphics, http://www.w3.org/TR/SVG) is a language for describing two- dimensional vector and mixed vector/raster graphics in XML.
(http://www.w3.org/TR/voicexml20) is an XML-based language for the definition of voice interfaces and dialogs, and it can be used in v-commerce and call centers.
(Wireless Markup Language, http://www.wapforum.org) is a markup language based on XML for specifying content and defining user interfaces for narrowband devices, including cellular phones and pagers. It has been optimized for small screens and limited memory capacity.
(XML-based Remote Procedure Calling protocol, http://www.xmlrpc.com) uses XML as the encoding, HTTP as the transport, and facilitates cross-platform remote procedure calls over the Internet.
(http://www.w3.org/TR/xforms) is an embryonic XML standard aimed at creating a platform-independent way of defining forms for the Web. An XForm is divided into the data model, instance data, and the user interface – allowing separation of presentation and content. This facilitates reuse, provides strong typing, and reduces the number of round-trips to the server, as well as promising device independence and a reduced need for scripting. Take a look at Chapter 9 for a working example based on XForms.
Content Management and Document Publishing
Using XML to store content enables a more advanced approach to personalization, as it allows for manipulation at the content level (opposed to the document level). That is, individual XML elements can be selected based on the user preferences. We could store preferences with client-side cookies, which we access to filter our XML content for each individual user. This filtering can be performed with the XML style sheet languages (XSL-FO and XSLT), allowing us to use a single source file, and manipulate it to create the appropriate content for each user, and even for multiple devices (cell phones, Web browsers, Adobe PDF, and so on).
Using XML for content management, instead of proprietary file formats, readily enables integrating that content with other applications, and facilitates searching for specific information.
WebDAV, the web-based Distributed Authoring and Versioning protocol from the IETF (http://www.webdav.org), provides an XML vocabulary for examining and maintaining web content. It can be used to create and manage content on remote servers, as if they were local servers in a distributed environment. WebDAV features include locking, metadata properties, namespace support, versioning, and access control. XML is used to define various WebDAV methods and properties.
Other standards related to XML metadata and content management include RDF (Resource Description Framework), PRISM (Publishing Requirements for Industry Standard Metadata), and ICE (Information and Content Exchange), whose description is beyond the scope of this chapter.
XML and Instant Messaging
Jabber (http://www.jabber.org/) is an example of how XML can be used for Instant Messaging. It is a set of XML-based protocols for real-time messaging and presence notification.
XML as a File Format
Many applications now use XML as a file format. For instance, .NET web application configuration data saved in .config files is written using XML syntax. Many other applications use XML files to store user preferences and other application data, such as Sun Microsystems's StarOffice XML file format (http://xml.openoffice.org/).
The qualities that make XML a good file format include its intrinsic hierarchical structure, coupled with its textual and extensible nature, and the large number of off-the-shelf tools available to process such documents.
XML in Vertical Industries
XML's simplicity and extensibility is attracting many individuals and industries, who are increasingly coming together to define a "community vocabulary" in XML, so that they can interoperate and build integrated systems more easily.
These community vocabularies include XML dialects already being used by a wide range of industries, such as finance (XBRL, for business reporting, and IFX for financial transactions), media and publishing (NewsML), insurance (ACORD), health (HL7), and shipping (TranXML), to name but a few. There are many more that also are rapidly gaining popularity.
Now that we've set the scene a little, and have seen some of the areas in business applications where XML can be useful, let's move on to look at some architectural issues.
The extremely brief history of web applications is a natural progression of developments in distributed architectures. The relative simplicity of HTTP-based web servers has allowed people who would never have tried to build a distributed application with prior technologies such as DCOM and CORBA to throw together simple distributed applications. At first, there was little emphasis on architecture of web apps, the priority being to get something up and running. Over time though, people asked their web servers to perform more and more advanced techniques. Developers began to rediscover distributed computing models in the attempt to improve performance and make their web applications reliable in the real world.
There are many models for distributed applications, just as there are many people who confuse scribbles on a cocktail napkin for revealed wisdom. To bring some order to the confusion, we'll look at a brief history of the growth of the Web, looking at how the models change to overcome problems encountered with what went before. The three models we will examine are:
Although each of these models applies to any sort of distributed application, we're going to focus on web applications, where the client is a web browser displaying pages with only limited processing power of its own. This 'thin-client' model is not always the case, but it seems to be where web development is headed. The lack of significant uptake for either Java applets or ActiveX controls on the client, in conjunction with divergent browsers on multiple platforms, has led to a tendency to favor processing on the server.
In the Beginning: Client-Server
The Web, of course, is inherently distributed. There is no such thing as a standalone web application. A client makes requests, which are answered by the server, and everything in the application except presentation is carried out by the server. While there are dynamic HTML applications relying heavily on client-side script as exceptions to this, general practice has been to keep functionality on the server in order to avoid the issue of varying browser capabilities. Logic and data are found there, leaving the client with nothing to do except make requests and display the answers. The model is very simple as this figure shows:
The client-server model offers a big advantage over standalone programming. The key processing in an application is confined to a single machine under the control of the application's owners. Once installation and configuration is out of the way, administrators keep watch over the server on an ongoing basis. This gives the application's owners a great deal of control, yet users all over the network – indeed, all over the world in the case of the Internet – can access the application. Life is good for the administrator.
The advent of the 'mass-market' Web came in the late 1980s and early 1990s, at a time when relational databases using the client-server model were rapidly gaining acceptance. Networks were becoming commonplace, and administrators and users were accustomed to a machine called a server living somewhere off in the ether serving up answers to queries. The fact that web servers sent their application data as HTML documents instead of binary-format recordsets meant little to the average user, protected by their browser from the intricacies of what was going on.
Programmers, however, were not satisfied with this model. From the programming viewpoint, such applications are almost as bad as standalone applications. Data and logic are tangled up in one great big mess, other applications cannot use the same data very easily, and the business rules in the server-side code must be duplicated when other programs need the same features. The only bright spot is that programmers can forget about presentation logic, leaving the task of displaying HTML tags to the browser.
The client-server model was perfect when web applications were simple static HTML pages. Even the very earliest ASP applications could fit with this model. As users clamored for more dynamic information, however, developers had to go back to the drawing board.
Architecture Reaches the Web: 3-Tier
3-tier architecture takes its name from the division of processing into three categories, or tiers:
The client handles request generation and user interface tasks as it did in the client-server model. The application logic tier, sometimes referred to simply as the middle tier, contains all the business rules and computation that make up the features of the application. The data tier holds all of the data in the application and enforces data integrity. Typically, the data tier consists of a relational database management system. The sequence of processing is as follows:
- Application logic
By separating the user interface (client), the logic (middle tier), and the data (data tier), we achieve a nice, clean separation of function. We can easily apply integrity checks to the database, and require any application or application tier running against it to pass these checks, thus preserving data integrity. Similarly, the business rules of the application are all located together, in the application tier. The application tier has to know how to query the data tier, but it doesn't need to know anything about maintaining and managing the data. Likewise, it doesn't concern itself with details of the user interface.
- The client generates a service request and transmits it to the application server.
- The application server produces a query corresponding to the client's request, and sends it to the data server.
- The application logic server applies business logic to the data as relevant, and returns the final answer to the client where it is displayed for the user.
The different tiers become more useful because, having been separated and provided with some sort of API, they can be readily used by other applications. For example, when customer data is centralized in a relational database, any application tier that needs customer information can access that database, often without needing any changes to the API. Similarly, once there is a single server that queries the customer database, any client that requires such information can simply go to that server. This aspect of 3-tier programming is generally less important than the integrity and software engineering benefits we just described, but it can nonetheless be valuable.
Note that the different tiers are logical abstractions and need not be separated in any physical sense. Many small web applications run their database on the web server due to a lack of resources, although this is bad practice from a security standpoint. Since the web server must by nature be available to the outside world, it is the most exposed link in the application. It is the most prone to attack, and if it should be compromised when the database resides on the same machine, the database will also be compromised. Generally speaking, though, the acceptance of the relational database prior to the advent of public web applications drove web architects to 3-tier systems fairly rapidly. It just makes sense to have the relational database kept distinct from the code that runs on the web server.
In practice, the distinction between the application logic and data tiers is often blurred. As an extreme example, there are applications that run almost entirely by stored procedures in an RDBMS. Such applications have effectively merged the two tiers, leaving us back in the realm of the client-server model. The stored procedures are physically resident on the data tier, but they implement a good deal of the business rules and application logic of the system. It is tricky to draw a clear line between the two tiers, and frequently it comes down to an arguable judgment call. When developing a good architecture, the effort of deciding where to draw the line, especially if you have to defend it to your peers, is more valuable than attempting to apply some magic formula good for all cases. A general-purpose rule can never apply equally to all possible applications, so you should take architectural rules simply as guidelines, which inform your design effort and guide your thought processes. An honest effort will shake out problems in your design. Slavish adherence to a rule with no thought to the current problem risks leaving many faults in the design.
At the other end, separating presentation – the function of the client – from application logic is harder than it might appear, particularly in web applications. Any ASP.NET code that creates HTML on the server is presentation code, yet you have undoubtedly written some of that as few browsers are ready to handle XML and XSLT on the client (Internet Explorer being the notable exception). Here, we explicitly decide to keep some presentation functions on the server, where the middle tier is hosted, but we strive to keep it distinct from application logic. In this way, we are observing the 3-tier architecture in spirit, if not fully realizing it in practice. An example of maintaining this split would be having application code that generates XML as its final product, then feeding that to code that generates HTML for presentation to the client. The XML code remains presentation-neutral and can be reused; the presentation code can be eliminated if we get better client-side support. In fact, XML-emitting application code is an important enabler for the next, and current, architecture: n-tier design.
Applications developed for a particular platform or architecture can benefit greatly from sharing useful sections of code. This not only saves time writing the code, but can also drastically reduce the effort required to fully test the application, compared to one developed from all-new source. If the developers have done things properly, this might take the form of function libraries or DLLs that can easily be used from a variety of applications. If they've been less meticulous, this may require the copying and pasting of source code for reuse.
Something similar holds true for web applications. It is a short step from writing static pages to incorporating simple scripts for a more dynamic experience, and that's pretty much how web applications got started. Likewise, it is a short step from linking to someone else's content to actually using their web code in your own site (while observing due legal requirements, of course). Google, for example, offers an HTTP interface to its service for adding web search capability to a site without its visual interface (see http://www.google.com/services/ for more information on Google's array of free and premium search solutions). Weather information is available from a number of sources and is frequently included dynamically on portal pages.
In short, we need some mechanism that supports and encourages reuse in web applications, a mechanism that conforms to the HTTP and text based architecture of the web.
Exchanging XML documents is one mechanism that meets these requirements, as many people have realized independently. Designing Distributed Applications (Wrox Press, 1999, ISBN 1-86100-227-0) examines this technique at length. The idea, in short, is to provide services through pairs of XML request/response documents. When a document written in the request vocabulary arrives over HTTP, it is assumed to be a request for service that is answered by returning a document written in the response vocabulary. The linkage is implicit, and is inferred by the code at either end through their knowledge of the XML vocabularies in use. Visual Studio .NET provides a similar service in the Web Service wizard, which generates code that exchanges XML documents as a means of communicating requests and responses.
This concept leads to a distributed architecture that is gaining popularity among developers of large- scale applications, particularly corporate intranet sites. In this architecture, we still segregate presentation, application logic, and data, but we are no longer confined to just three tiers. We may have multiple implementations of logic and data, and we may even have an additional tier for combining application logic results before sending them on for presentation. The number of tiers isn't important (at least for theoretical purposes; practical performance will constrain you); the separation of logic and data, as well as the encapsulation of functions into discrete services, is what characterizes n-tier architecture. Consider the illustration below:
The client has no idea that the result is a composite of the efforts of multiple services, nor does it need to have this information. Future changes in Web Services, code deployment, or functional implementation will not affect the client. Of further benefit is the fact that the Web Services are not tied to the web server or the client. Multiple applications can call on any Web Service. In fact, application logic can call Web Services and use their results without any presentation to a user.
- A client sends a request to a web server. The server uses several Web Services, bits of application logic, to provide partial answers, which, taken together, result in the answer the client requested. A portal page is a great example: it might include news, weather, and stock prices, each of which could come from a different provider.
- The web server, then, breaks the client request into a series of HTTP requests to the Web Services needed to get the required information.
- The Web Services, in turn, may make data requests to obtain raw information. They could also, in theory, make request of their own to other Web Services, leading to many, many tiers of logic.
- The web server receives the responses from the Web Services, and combines them into a composite page that it eventually returns to the client as the response to the client's original request.
This architecture is very compatible with the web platform. HTTP requests are used for communication, XML, a textual format, conveys data in an open and platform-neutral manner, and all components are interconnected with HTTP links. The use of proprietary XML vocabularies that implicitly denote either requests or responses is a weak point of the architecture, though, as it precludes the development of general purpose software for connecting Web Services to applications.
One way to solve this is would be to create an open standard for Web Service communication. At the moment, the best effort is SOAP, which provides an XML envelope for conveying XML documents that can represent function calls with their required parameters. Web Services created with Visual Studio .NET's Web Service template support SOAP. SOAP is a de facto standard, and so general purpose toolkits for creating and consuming SOAP messages can be produced. Such toolkits can pop the parameters out of the request document and present them to your application code as actual function or method parameters.
SOAP implementations generally adhere to the SOAP 1.1 version, though version 1.2 is in draft form (http://www.w3.org/TR/soap12-part0 and http://www.w3.org/TR/soap12-part1/) and implementations are migrating to it. SOAP was originally an ad hoc effort of several software vendors, but has now been handed over to the W3C, where further development is under way in the form of XML Protocol (http://www.w3.org/TR/xmlp-am/).
Another way to resolve this would be with the aid of integration servers. These are proprietary server software products offered by a variety of vendors that act as middleware between applications for the purpose of integrating them. They handle issues of protocol and format translation. A message could come in as an XML document on SMTP and be sent back out as a different XML document (differing in form, but with the same data content) over HTTP, for example. Some also add business process semantics, to ensure that a series of messages adheres to the established business process. Some of these products adhere to standards advanced by various consortia such as RosettaNet (http://www.rosettanet.org), while others, such as Microsoft BizTalk Server (http://www.microsoft.com/biztalk) are open to your own business processes. In addition to Microsoft, established vendors include Ariba (http://www.ariba.com) and CommerceOne (http://www.commerceone.com).
So now we've had a close look at three generic architectures, finishing up with the n-tier model, the likely future of web applications. We've seen how XML can fulfill many internal needs of these architectures. Now we'll examine two common web applications that benefit from a 3- or n-tier architecture with XML. These applications are:
- Content sites – high volume web sites with changing content consisting primarily of HTML pages rather than interactive code, for example, a news site
- Intranet applications – medium volume sites providing application access on an intranet
A site with a great deal of content, such as an online newspaper or magazine, might not seem to be an application at all. The site framework seldom changes, though new documents are frequently added and old ones removed. There is rarely much in the way of interactivity, aside from a search feature for the site. But XML offers some advantages for maintaining the site and facilitating searching.
One issue with such sites is that they periodically undergo style changes. Hand written HTML is therefore out of the question as you would scarcely want to redo all the pages just to change style and layout. The use of cascading style sheets addresses many of the styling issues, but they lack the ability to truly transform and rearrange pages if so desired. The word "transform" there might provide a clue as to what I'm getting at: XSLT. If we store the content in XML, we can manipulate it to produce the visual effects we desire through an XSLT style sheet. When a site redesign is warranted, we just change the style sheet. We can even update links to reflect hosting changes with XSLT, a feat that is impossible in CSS. You should not, however, use XSLT dynamically for a high volume site. The performance overhead from even a fast XSLT processor is something a high-volume site cannot afford. Instead, use XSLT to perform a batch conversion of your XML documents when you redesign, then serve up the resultant HTML as static pages between site designs. New documents are transformed once, as they are added to the site. This gives the site all the speed of static HTML while still maintaining the ability to automate site redesign.
You might ask why you would want to use XML instead of a database for the information content of the site. Well, firstly, this is not necessarily an either-or proposition. Increasingly, databases can store XML documents, or access relational data using XML documents, thereby giving you the best of both worlds. Secondly, we can use XPath to enhance our search capability. Once information is marked up as XML, we can search by specific elements, such as, title, summary, author byline, or body. Furthermore, we can selectively publish fragments with another XSLT style sheet. For example, we might select title and summary only for people browsing with PDAs or customers who have subscribed to a clipping service. Similarly, we might mark some content as premium content, whether it be by whole page or by subsections of individual pages.
A substantially different architecture is required for intranet applications. These sites provide access to sophisticated corporate functions such as personnel management applications or retirement fund selections. If we are writing entirely new functions using the latest technology and platforms, there isn't a problem. We can just write our applications using ASP.NET. XML is optional. The problem for intranet applications arises because we often have to provide access to legacy systems, or at least exchange information with them.
The easiest way to deal with this is to wrap the legacy code in a Web Service. This only works when the legacy applications offer an API that we can call from .NET. COM components work quite well, but older interfaces can pose a problem. This is where Web Services can help, by isolating the rest of the system from the legacy, XML-illiterate code. Everything beyond the Web Service is XML, limiting the spread of legacy data structures. The situation is depicted below:
A bigger problem arises when the code cannot be directly called by .NET or when scalability concerns preclude the use of synchronous SOAP calls. If we require our system to achieve close to 100% uptime, we cannot afford to drop requests as is the case when traffic to a synchronous service like SOAP spikes beyond supported levels. The buffering offered by a queued solution is needed, and in such cases, we need the help of an integration server, such as BizTalk Server. We can communicate with the integration server, and leave it to pass the message on in a protocol that is supported by the legacy application. This might at first seem to leave out many existing applications, until we realize that most integration servers support exchanges via disk files. The server monitors a particular directory for the appearance of a file, or it writes a file to the directory that is monitored by the legacy application. This is a very common, least-common-denominator approach. Now consider the web application architecture depicted opposite:
The asynchronous communication of this design makes it inherently scalable. The client gets an immediate response via the initial web application indicating that the request has been submitted. The communications protocol with the legacy application should provide a buffer – typically through some sort of messaging middleware like MSMQ or through files accumulating on disk. If the protocol is synchronous, you probably could have wrapped it with a SOAP Web Service.
- Request arrives from the client tier through an ASP.NET application, which writes an XML message to the integration server
- Integration server sends a message to the legacy application, in this case via disk-based file transfer. Format translation occurs en route.
- Legacy application receives the message and produces output
- Output message is exchanged with the integration server via the supported protocol
- Integration server sends message to client via e-mail, possibly as XSLT styled XML
- Upon receiving notification via e-mail, client returns via ASP.NET and retrieves a result written to a database by the integration server
There are long term plans for asynchronous Web Services using SOAP, but present implementations use synchronous calls via HTTP.
This design is also clearly n-tier. The ASP.NET applications provide the application logic, as does the legacy application. The integration server may be considered application logic or part of the infrastructure. Any database used by the legacy application is data, as is the database used by the alternative Step 6, above.
Although we've used the example of an intranet application, this architecture can apply to e-commerce sites as well. In that case, the client tier is located outside the corporate firewall, but order fulfillment and billing systems are internal, possibly legacy, applications. In such a case, the Web Service would typically be deployed in a demilitarized zone, or DMZ, between two firewalls. The first firewall protects the web server hosting the service and provides minimal protection. The web server takes steps to authenticate requests before passing them through the second, more stringent firewall protecting the internal network from the Internet. The second architecture, using an integration server, is preferred as it scales better, but you can use the less costly Web Services architecture if volume is moderate or the Web Services do not involve much processing.
ASP.NET Web Development
So far we have seen what XML is and some of its general applications. Let's now look at how XML fits in with the ASP.NET world and its role in the development of ASP.NET web applications.
Welcome to ASP.NET
ASP.NET represents the next generation of web development on the Windows platform. It is an evolutionary and revolutionary improvement on traditional ASP 3.0, and many things have changed. It is a totally new platform (although there's a fair amount of backward compatibility) designed to support high-performance scalable web applications.
ASP.NET changes all this. It runs in a compiled environment, such that the first time an aspx page is called after the source code has changed, the .NET Framework compiles and builds the code, and caches it in a binary format. Each subsequent request does not then need to parse the source, and can use the cached binary version to process the request, giving a substantial performance boost.
In ASP.NET, the separation of presentation from the program logic is achieved via the concept of code-behind files, where the main ASPX page has a corresponding language file behind it. For instance, default.aspx would contain the presentation code (HTML and client-side scripts), while an associated file, such as default.aspx.cs, would contain the C# code for that page. This allows us to keep code nicely separated from its presentation details.
ASP.NET includes many other new features related to Web Forms, such as deployment, state management, caching, configuration, debugging, data access, as well as Web Services. It is however beyond the scope of this chapter to provide a complete discussion of all these topics. Try Professional ASP.NET 1.0, Special Edition (Wrox Press, 1-86100-703-5) if that is what you need. Here, we'll focus on the XML and Web Services features of ASP.NET.
The Role of XML in ASP.NET
The .NET Framework itself makes use of XML internally in many situations, and thus it allows XML to be easily used from our applications. In short, XML pervades the entire .NET Framework, and ASP.NET's XML integration can be used to build highly extensible web sites and Web Services. In this section, we'll briefly look at the XML integration in the .NET Framework, specifically in ASP.NET.
The System.Xml Namespace
This is the core namespace that contains classes which can:
Almost all applications that use XML in any way will refer to the System.Xml namespace in order to use one or more of the classes that it contains.
- Create and process XML documents using a pull-based streaming API (Chapter 2) or the Document Object Model (DOM, Chapter 3)
- Query XML documents (using XPath, Chapter 4)
- Transform XML documents (using XSLT, Chapter 5)
- Validate XML documents (using a DTD, or an XDR or XSD schema, Chapter 2)
- Manipulate relational or XML data from a database using the DOM (XmlDataDocument class, Chapter 6)
Chapters 2 through 4 focus on the System.Xml namespace and discuss how these classes can be used in ASP.NET web applications.
As well as web sites, .NET web applications can represent Web Services, which can be defined in a sentence thus:
ASP.NET Web Services are programmable logic that can be accessed from anywhere on the Internet, using HTTP (GET/POST/SOAP) and XML.
We'll talk about this a little more in the section XML Messaging towards the end of this chapter, and in detail in Chapter 8.
SQLXML Managed Classes
Although not part of the core .NET Framework, the SQLXML managed classes are available as a separate download from http://www.microsoft.com/sql/techinfo/xml/default.asp. These classes form part of the Microsoft.Data.SqlXml namespace and allow access to SQL Server 2000's native and extended XML features. SQLXML managed classes can be used in our ASP.NET applications to build scalable and extensible web applications, and they are discussed in detail in Chapter 7.
The ADO.NET DataSet Class
Probably the most fundamental design change in the data access model in the .NET Framework is the differentiation of the objects that provide connected database access from those that provide disconnected access. In regular ADO, we use the same objects and interfaces for both connected and disconnected data access, causing lot of confusion. The improved ADO.NET data access API in .NET provides stream-based classes that implement the connected layer, and a new class called DataSet that implements the disconnected layer.
The DataSet can be thought of as an in-memory representation of data records. It can easily be serialized as XML, and conversely it can be populated using data from an XML document. The .NET data access classes are present in the System.Data namespace and its sub-namespaces.
Another marked improvement in ADO.NET is the ability to easily bind the data to graphical controls. We'll talk more about the role of ADO.NET and the DataSet when dealing with XML in Chapter 6.
The .config Files
With ASP.NET, Microsoft has introduced the concept of XCopy deployment, which means that the deployment of an application does not require any registry changes or even stopping the web server. The name comes from the fact that applications can be deployed by just copying the files onto the server with the DOS XCopy command.
Prior to .NET, all web application configuration data was stored in the IIS metabase. The .NET Framework changes this with the notion of XML-based extensible configuration files to store many configuration details. These files have the .config extension – and play an important role in XCopy deployment. As these files are plain text XML files, configuration data can be edited using any text editor, rather than a specialized tool such as the IIS admin console. The .config files are divided into three main categories, containing application, machine, and security settings.
C# Code Documentation
Another interesting new feature is found in C# (or strictly speaking, C# .NET), and extends the syntax for comments beyond the standard // and /*...*/, to create a new type that begins with three slashes (///). Within these, we can place XML tags and descriptive text to document the source code and its methods. The C# complier is then able to extract this information and automatically generate XML documentation files. It can also generate HTML documentation directly from these comments.
Currently, this feature is only available in C#, and none of the other .NET languages support it.
XML 1.0 Syntax
The XML 1.0 (Second Edition) W3C recommendation (http://www.w3.org/TR/REC-xml) defines the basic XML syntax. As we know, XML documents are text documents that structure data, and bear some similarity to HTML documents. However as noted earlier, tags in XML, unlike tags in HTML, are completely user-definable: there are virtually no 'reserved' tags. Also unlike HTML, XML is case-sensitive.
An XML document (or data object) has one and only one root element – that is, top level element – which may contain any number of child elements within it. All elements must be delimited by start- and end-tags, and be properly nested without overlap. Any element may contain attributes, child elements, and character data. The XML 1.0 specification allows most of the characters defined by 16-bit Unicode 2.0 (which includes UTF-8, UTF-16, and many other encodings), hence making XML truly a global standard.
The XML specification identifies five characters (<, >, &, ', and ") that have a special meaning and hence if any of these characters is required, the alternative entity references (<, >, &, ', and ") must be used in their place.
In addition to elements and attributes, an XML document may contain other special purpose tags such as comments (<!-- ... -->), processing instructions (<? ... ?>), and CDATA (<![CDATA[ ... ]]>) sections.
All documents that conform to the XML 1.0 rules are known as well-formed XML documents. If a well-formed document also meets further validity constraints (defined by a DTD or schema), it is known as a valid XML document. We'll discuss XML validity later in this chapter.
It is a good practice, although not a strict requirement, to begin an XML document with the XML declaration. If present, it should be the very first line in the document. The XML declaration identifies the XML version to which the document syntax adheres (a required attribute), the document encoding scheme (optional), and if the document has any external dependencies (again optional).
Another extension to the XML 1.0 specification is XML Base, where an xml:base attribute may be included on an element to define a base URI for that element and all descendent elements. This base URI allows relative links in a similar manner to the HTML element
The XML specification defines two special attributes that can be used within any element in an XML document. The first, xml:space, is used to control whitespace handling and the second, xml:lang, is used to identify the language contained within a particular element. The xml:lang attribute allows internationalized versions of information to be presented, and makes it easier for an application to know the language used for the data in the element.
An XML document may contain whitespace (space characters, tabs, carriage returns, or line feeds) at various places. Sometimes whitespace is added to indent the XML document for better readability, and when an application is processing this document, the whitespace can be ignored. At other times however, the spaces are significant, and should be preserved. We can use the xml:space attribute on the element to indicate whether the parser should preserve whitespace or use its default whitespace handling. The xml:space attribute can have one of two values: preserve or default.
According to the W3C XML specification, if the whitespace is found within the mixed element content (elements containing character data and optionally child elements) or inside the scope of an xml:space='preserve' attribute, the whitespace must be preserved and passed without modification to the application. Any other whitespace can be ignored.
With MSXML 4.0 and the .NET XML classes in the System.Xml namespace, we can use the PreserveWhitespace property in the code to indicate if the whitespace should be preserved or not. In other words, if we would like to preserve the whitespace for an XML document, we can either use the xml:space attribute with the elements in the XML document or set the PreserveWhitespace property in the code to true (default is false).
Let's look at an example of this. Consider the following XML document, saved as c:\test.xml:
<Root> <Child>Data</Child> </Root>
Note that there are five space characters before and after the <Child> element.
We could create a simple C# console application containing the following code in the Class1.cs file, and when we ran it, we'd see that the whitespace has not been preserved in the XML displayed on screen, and in fact carriage return characters have been added (you might want to place a breakpoint on the closing brace of the Main method):
static void Main(string args)
XmlDocument xmlDOMDoc = new XmlDocument();
There are two ways we could preserve the whitespace. The first is to add the xml:space attribute to the XML document. Change the c:\test.xml file as shown below:
<Root xml:space='preserve'> <Child>Data</Child> </Root>
Run the above code again and this time, the whitespace is preserved and the document will appear exactly as it does in the file.
The other way is to set the PreserveWhitespace property to true in the code. Add the following line to the Main method:
XmlDocument xmlDOMDoc = new XmlDocument();
xmlDOMDoc.PreserveWhitespace = true;
Now whitespace will be preserved, even without the xml:space attribute in the XML file.
Likely Changes in XML 1.1
On April 25, 2002, the W3C announced the last call working draft of XML 1.1 (codenamed Blueberry), at http://www.w3.org/TR/xml11/. The XML 1.1 draft outlines two changes of note, although they are unlikely to have a major impact on most web developers. These changes allow a broader range of Unicode characters, and improve the handling of the line-end character.
In XML 1.0, characters not present in Unicode 2.0 (and some forbidden names) cannot be used as names; XML 1.1 changes this so that any Unicode character can be used for names (with the exception of a few forbidden names). This change was made to make sure that as the Unicode standard evolves (the current version is 3.2), there won't be a consequent need to explicitly change the XML standard.
The other important change relates to how the end-of-line characters are treated. Microsoft uses CR-LF (hex #xD #xA) to represent end-of-line characters, while Unix (and GNU/Linux) use LF (#xA), and MacOS uses CR (#xD). XML 1.0 currently requires processors to normalize all these newline characters into #xA. The XML 1.1 working draft adds the IBM mainframe newline characters and requires XML processors to normalize mainframe-specific newline characters (#xD #x85, #x85, and #x2028) to #xA.
Well-formed XML documents must meet the following requirements:
Without further delay, let's look at an example of the following well-formed XML document, called MyEvents.xml:
- All tags must be closed
- Tags are case sensitive
- The XML document must have a single root element
- Elements must be nested properly without overlap
- No element may have two attributes with the same name
- Attribute values must be enclosed in quotes (using either ' or ")
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MyEvents xmlns='uuid:06F699FA-C945-459a-BFCE-CFED4A4C7D51' >
<!-- Live Webinars -->
<Webinar type='live' ID='1'>
<Title>ProductA Kick-Start Webinar</Title>
<Time zone='CST' AMorPM='PM'>3:00</Time>
<![CDATA[© 2002 ABC & PQR Corp.]]>
<Webinar type='live' ID='2'>
<Title>ProductB In-depth Webinar</Title>
<Time zone='CST' AMorPM='AM'>10:00</Time>
<![CDATA[© 2002 ABC & PQR Corp.]]>
<!-- Recorded Webinars -->
<!-- *** None *** -->
<!-- Trade shows -->
<Title>ABC Magazine Live!</Title>
<Location>MGM Grand Hotel and Casino</Location>
The above XML document illustrates various points that we have discussed so far. It begins with an XML declaration statement indicating that the syntax follows the XML 1.0 specification, the document encoding is UTF-8, and the standalone="yes" attribute indicates that this document does not depend on any other external resource (such as a DTD, schema, or style sheet). The above document contains a single root element (<MyEvents>), which in turn contains various child elements (two <Webinar> elements, a <TradeShow> element, and several comments). Do not worry about the xmlns attribute yet, as we discuss this in the next section. Note also the attributes, comments, and CDATA sections in the above document.
Namespaces in XML
Wherever they may be found, namespaces generally serve two basic purposes
XML namespaces also serve these two purposes, and are defined as an extension to the XML 1.0 specification.
- To group related information under one umbrella
- To avoid name collision between different groups
In the above sample XML document, we have various element names (such as MyEvents, Webinar, TradeShow, and so on). It is possible that somebody else might also use the same names in their XML documents, but for something not quite the same as we did. So how can the processing application associate elements with their correct meanings? The solution is provided by XML namespaces.
While writing XML documents, it is good practice to use namespaces, to avoid the potential for name clashes. All elements or attributes belonging to a given namespace can be prefixed with the name of the namespace, thus making a unique identifier. Hence, namespace names are required to be unique (in the above XML, uuid:06F699FA-C945-459a-BFCE-CFED4A4C7D51 is the namespace name), and it is for this reason that URLs are often chosen for the purpose. For instance, if our company has its own URL, we can be fairly sure that no-one else will use that URL in their namespaces. For instance, Wrox Press might choose namespace names for its XML documents such as http://www.Wrox.com/Accounting, http://www.Wrox.com/Marketing, and so on; while another company, say Friends of ED, might use http://www.friendsofED.com/Accounting, http://www.friendsofED.com/Marketing, and so on.
Notice that we don't actually prefix any of the element names with a namespace name in the above example XML document. This is because we have a default namespace declaration on the root element (xmlns='uuid:06F699FA-C945-459a-BFCE-CFED4A4C7D51'), which binds that element and all contained elements to this URI. By using the xmlns syntax, all the elements in the document now belong to the uuid:06F699FA-C945-459a-BFCE-CFED4A4C7D51 namespace (more precisely, all descendent elements of the element defining the namespace). Note that the default namespace declaration has no effect upon attribute names, and so in the above XML document, the attributes do not explicitly belong to any namespace.
It is quite possible for an XML document to contain multiple namespaces for various elements and attributes, and although we could prefix any element or attribute with the full namespace name, it would be very cumbersome in practice. A better solution in XML namespaces is to define short prefixes, which we can then use instead of the long namespace names. An element or attribute name without a prefix is referred as the local name of the element, and with the prefix it is known as the qualified name or QName.
Consider the following example:
<evts:Webinar evts:type='live' evts:ID='1' ol:vcsItemID="DER-ER" />
The above XML document declares two namespace names with the prefixes evts and ol assigned. These short prefixes save our writing the full namespace names over and over. All elements and attributes above belong to the evts namespace, except vcsItemID, which belongs to the ol namespace. Note how the attributes are namespace prefixed. The name evts:Webinar is an example of a qualified name (or QName) for this document, while Webinar is the corresponding local name.
XML Information Set
The XML Information Set (InfoSet) is a W3C specification that tries to help make sure that as new XML languages are drawn up, they exploit consistent definitions and terminology, and that the dialects used do not create any confusion.
The current XML InfoSet W3C recommendation (http://www.w3.org/TR/xml-infoset/) defines an abstract data set for well-formed XML data that also complies with the XML Namespaces naming rules. There is no requirement for an XML document to be valid in order to have an information set.
Today, there are many tools available to create, read, parse, and process XML documents from our programs. The primary goal of these tools is to efficiently extract the data stored in between tags, without having to text-parse the document. Almost all of these tools are based on two standard abstract APIs – the Document Object Model (DOM) or the Simple API for XML (SAX). We'll have a look at these two now.
Document Object Model (DOM)
The DOM is an abstract API defined by the W3C (http://www.w3.org/DOM) to process XML documents. It is a language- and platform-independent abstract API that any parser can implement, and it allows applications to create, read, and modify XML documents.
Using the DOM, the parser loads the entire XML document into the memory at once as a tree, providing random access to it for searching and modifying any element in the document.
Microsoft XML Core Services (MSXML) version 4.0 (http://msdn.microsoft.com/xml) supports the DOM. Other freely available DOM implementations include JAXP from Sun Microsystems (http://java.sun.com/xml/) and Xerces from the Apache XML foundation (http://xml.apache.org).
Most of the current DOM implementations (including that in .NET) support DOM Level 1 Core (http://www.w3.org/TR/DOM-Level-1) and DOM Level 2 Core (http://www.w3.org/TR/DOM-Level-2-Core). W3C recently announced the DOM Level 3 Core Working Draft (http://www.w3.org/TR/DOM-Level-3-Core).
Simple API for XML (SAX)
SAX, like DOM, defines a set of abstract interfaces for processing XML. It differs from the DOM in that, instead of loading the entire document into memory, SAX follows a streaming model, reading an XML document character by character as a stream, and generating events as each element or attribute is encountered. The SAX-based parser passes these events up to the application through various notification interfaces.
As DOM loads the entire document in the memory, the DOM parser checks the well-formedness (and optionally validity) of documents on opening them; whereas since SAX reads the XML document as a character-by-character stream, without caching the document in the memory, it is not able to check for well-formedness of the document.
SAX is an excellent lightweight alternative to DOM for processing XML documents. Unlike DOM, SAX is not a product of the W3C, and was created by the XML-DEV mailing list members, led by David Megginson.
Note that SAX is a stream-based API that uses the push model, where XML documents are read as a continuous stream, and the SAX engine fires events for each item as it is encountered. SAX allows very simple parser logic, although the application logic required to use it is consequently more complex. The .NET Framework contains a class (called XmlReader) which also processes XML as a stream, but using the pull model, where the parser advances from item to item in an XML document when instructed to do so by the application. This can simplify application logic, while providing the same benefits as SAX. The XmlReader class provides the best of both worlds: streaming high-performance parsing (as in SAX), and simplicity of usage (as in the DOM). Neither SAX nor XmlReader maintains state, and so we must provide our own means of preserving information from XML items that have been read if needed. We'll look at XMLReader much more closely in Chapter 2.
By not fully loading XML documents into memory, SAX requires less system resources and proves to be a very efficient API for parsing large XML documents. However, programming SAX is not as simple as the DOM, firstly because we must implement notification interfaces and maintain state, and also because SAX does not allow random access to the document or provide editing functionality as does the DOM.
Most of the current SAX implementations, including MSXML 4.0, JAXP, and Xerces, support SAX 2.0. The .NET Framework does not support true SAX, but an alternative (and simpler to work with) pull- model stream-based parsing API (the XmlReader classes in the System.Xml namespace). As we shall see in Chapter 2, we can however use XmlReader to read a document according to a push model should we wish.
XML Data Binding and XML Serialization
XML data binding refers to the mapping of XML elements and attributes onto a programmatic data model, in order to use the XML data directly as components of an application, and vice versa. In .NET, data binding allows us to link data within an XML file directly to a DataSet, which we can then display in a DataGrid. Any changes to the XML data will appear immediately in the DataGrid, and conversely, any changes made to the values in the DataGrid will be reflected immediately in the XML file.
XML serialization is the name given to the rendering of programmatic data as XML for transmission between computers or storage on some external system. An obvious analogy would be packaging eggs in a carton for transport and storage, which can be unpackaged intact (deserialized) when they are to be used. In .NET, an object can be marshaled (or serialized) as a XML stream, and at the other end, an XML stream can be un-marshaled (or deserialized) back to an object. This allows programmers to work naturally in the native code of the programming language, while at the same time preserving the logical structure and the meaning of the original data, and can be readily used instead of using the low-level DOM/SAX API to manipulate the XML data structural components.
The .NET Framework namespace System.Xml.Serialization contains the classes that serialize objects into XML streams, and deserialize them back again.
One of the primary goals of XML is to enable the free exchange of structured data between organizations and applications. To do this, the XML document format that will be used for the exchange of information must first be defined and agreed upon. It's fairly elementary to ensure that any XML document is well-formed, but we also need to ensure that it is valid: in other words that it strictly follows the agreed structure, business logic, and rules. We can do this by defining a schema that we can then use to validate any XML document.
The initial solution for defining XML document structure was the existing Document Type Definition (DTD) syntax. However, it was soon realized that DTDs are very restrictive; they do not support strong data typing, are not extensible, and can perform only limited validation with regards to the sequence and frequency of elements.
The XML Schema Definition (XSD) language was introduced by the W3C as a replacement for DTDs. XML Schemas (http://www.w3.org/XML/Schema) overcome all the shortcomings of DTDs, and they provide a very flexible and extensible mechanism for defining the structure of XML. As with so many other XML-related specifications from the W3C stables, XML Schemas are themselves constructed from XML syntax, with the many advantages that brings.
XML Schemas can be used for much more than merely validating an XML document. Visual Studio .NET, for instance, uses schemas to determine possibilities for the IDE's IntelliSense feature, allowing it to auto-complete partially typed keywords. In addition, XML Schemas are also used in database and object technologies.
In May 2001, XML Schema 1.0 reached W3C Recommendation status, meaning that that version of the specification will not be modified further. The Recommendation is divided into three parts:
While the W3C was finalizing XSD, Microsoft created XDR (XML-Data Reduced) so that it could start using XML Schemas as soon as possible. Various Microsoft products (such as MSXML 3, SQL Server 2000, and BizTalk Server 2000) still support and use XDR.
The current release of the MSXML parser and the .NET Framework both fully support the XML Schema (XSD) W3C Recommendation. XDR is still supported in .NET – but not recommended. Microsoft recommends, as do I, XSD for all schema-related purposes.
The W3C is currently working on the XML Schema 1.1 standard (http://www.w3.org/XML/Schema).
Navigating, Transforming, and Formatting XML
Among complementary standards created by the W3C are some that further help process XML documents. In this section, we'll discuss three such standards: XPath, XSLT, and XSL-FO.
Right now there is only one widely supported technology for searching through XML documents and retrieving specific components, and it is the XML Path Language, or XPath. Once we have structured data available in XML format, we can easily find the information we require with XPath, a W3C specification that enables the querying, locating, and filtering of elements or attributes within an XML document.
XPath is based on the notion that all XML documents can be visualized as a hierarchical tree; it is a language for expressing paths through such trees from one leaf, or node, of the tree to another. It enables us to retrieve all elements or attributes satisfying a given set of criteria. Most XPath implementations provide very fast random-access retrieval of XML content when we know something about the structure of a document.
XPath provides a declarative notation, known as an expression or a pattern, to specify a particular set of nodes from the source XML document. An XPath expression describes a path up through the XML 'tree' using a slash-separated list of discrete steps. XPath provides basic facilities for manipulation of strings, numbers and Booleans that can be applied within these steps.
Let's look at an example XPath expression to select data from the MyEvents.xml document:
This expression selects the <Title> child element of the <Webinar> element that has an attribute called ID with the value 2. XPath expressions are namespace aware, and thus we would need to specify the namespace of the elements in a real-world expression. I'll leave this, and the complete explanation of XPath syntax, for Chapter 4.
XPath .NET classes are found in the System.Xml.XPath namespace (also discussed in Chapter 4), and include the XPathDocument class to load an XML document, and the XPathNavigator class for executing complex expressions.
XPath 1.0 (http://www.w3.org/TR/xpath) was published as a W3C Recommendation on December 20th 2001, and XPath 2.0 is currently at working draft stage (http://www.w3.org/TR/xpath20/). XPath is used by other standards such as XSLT, XPointer, and XQuery. The current releases of MSXML and the .NET Framework implement XPath 1.0.
XSL, the Extensible Stylesheet Language, is an XML-based language to create style sheets. XSL covers two technologies under its umbrella:
In this section, we'll talk about XSLT, and discuss XSL-FO in the next section.
- XSL Transformations (XSLT) is a declarative language used to transform XML documents from one format to another.
- XSL-Formatting Objects (XSL-FO) is a page-formatting language with major focus on very precisely specifying the visual presentation of XML.
Earlier in the chapter we learned about XML's role in separating data from its presentation. XSLT has a lot to offer here. A single source XML document can be transformed to various output formats (HTML, WML, XHTML, and so on) using an appropriate XSLT stylesheet.
We've also learned that XML acts as glue for integrating e-business and B2B applications. XSLT is the key player as it can transform one XML dialect to any another.
There are many other potential uses for XSLT, such as performing client-side transformation of raw XML in a web application, thus reducing the load on the server. This would require a browser with XSLT support of course, but your web server can detect the user agent type to determine this.
Let's look at an example XSLT stylesheet, called renderHTML.xsl:
<xsl:output method="html" />
<xsl:value-of select="src:Title" />
This style sheet provides a good demonstration of the value of namespaces in XML. Note the two prefixes declared at the top of this style sheet: one is xsl and denotes elements related to XSLT, and the other is src, for elements from the source XML file. This prevents any ambiguity, should our own XML dialect also define <template> elements, say. The <stylesheet> element also specifies the exclude-result-prefixes attribute with "xsl src" as its value, thus preventing elements bound to these prefixes from appearing in the result tree.
When the above style sheet is applied on our sample MyEvents.xml XML document discussed earlier, it produces the following HTML output:
<a rel="nofollow" href="http://www.company.com/events/events.asp?ID=1">ProductA Kick-Start Webinar</a>
<a rel="nofollow" href="http://www.company.com/events/events.asp?ID=2">ProductB In-depth Webinar</a>
Essentially, this works by embedding XSLT elements inside HTML code, and these elements transform certain elements from the source XML (as specified by XPath expressions) to an appropriate HTML form for viewing
The simplest method to try out the above style sheet (without writing a single line of code), is to add the following processing instruction just below the XML declaration (<?xml ...?>) in the XML file, and opening it in Internet Explorer:
<?xml-stylesheet type="text/xsl" href="renderHTML.xsl" ?>
As renderHTML.xsl uses the final release XSLT namespace (http://www.w3.org/1999/XSL/Transform) you'll need to run the above example with Internet Explorer 6.0 (which installs MSXML 3.0 in replace mode) or with Internet Explorer 5.0+ and make sure it is using MSXML 3.0.
The current release of MSXML and the .NET Framework support XSLT 1.0 (a W3C Recommendation at http://www.w3.org/TR/xslt).
Note that the W3C Working Draft of XSLT 1.1 (http://www.w3.org/TR/xslt11/) was frozen, not to be continued, on release of the XSLT 2.0 Working Draft (http://www.w3.org/TR/xslt20req), so refer to XSL 2.0 to track the progress of the XSLT standard.
XSL-FO, now also simply called XSL, is a W3C Recommendation (http://www.w3.org/TR/xsl) designed to help in publishing XML documents (both printing and displaying electronically), and it mainly focuses on the document layout and structure (such as output document dimensions, margins, headers, footers, positioning, font, color, and the like).
Currently, MSXML and the .NET Framework do not support XSL-FO.
Other Standards in the XML Family
In addition to XPath and XSLT, W3C is working on various other standards related to XML. Even though there isn't as yet a great deal of support for these standards, it is nonetheless useful to be aware of them. In this section, we'll briefly discuss these standards and see where they are as far as the W3C standardization process is concerned.
XLink and XPointer
Resembling an HTML-type linking mechanism for XML documents is the XML Linking Language, XLink. XLink is a W3C Recommendation that describes elements that can be inserted into XML documents to create and describe links between resources. This specification not only allows simple one-way links between two resources, but also supports more sophisticated bi-directional links, 'multi- choice' links, and also links between resources that don't normally have the ability to contain links, such as image files.
XLink v1.0 is now a W3C Recommendation at http://www.w3.org/TR/xlink/.
XLink can be used to create a link in one document pointing to another XML document. To point to just a part of another XML document, we use the XML Pointer Language (XPointer). XPointer, currently in candidate recommendation status, is a W3C specification based on XPath, and allows referring to some portion (a sub-tree, attributes, text characters, etc.) of another XML document.
The specification lives at http://www.w3.org/TR/xptr.
The W3C XML Query Working Group is tasked to formulate a universal XML-based query language that can be used to access XML, relational, and other data stores. XQuery is intended to provide a vendor-independent, powerful, but easy-to-use method for query and retrieval of XML and non-XML (exposed as XML by some middleware) data. XQuery can be treated as a superset to XPath 2.0.
Microsoft has created an online demo, and downloadable .NET libraries, that can be used to play about with the XQuery 1.0 Working Draft. More details on this can be found at http://126.96.36.199.
There are already many commercial products available that have implemented XQuery, such as those listed at http://www.w3.org/XML/Query#products.
XQuery 1.0 is currently in Working Draft status, and is available at http://www.w3.org/TR/xquery/.
XHTML is nothing but HTML 4.01 written in conformance to XML rules. This means XHTML documents must be well-formed. The W3C tagline for XHTML specification is "a reformulation of HTML 4 in XML 1.0" (http://www.w3.org/TR/xhtml1).
The W3C has also designed modularized XHTML (http://www.w3.org/TR/xhtml-modularization/), which essentially splits XHTML into separate abstract modules, each of which represents some specific functionality in XHTML.
Finally, a simplified and minimal set of these modules have been defined as XHTML Basic (http://www.w3.org/TR/xhtml-basic).
All three W3C specifications – XHTML 1.0, Modularization of XHTML, and XHTML Basic – have reached Recommendation status.
Forms are an integral part of the Web. Nearly all user interaction on the Web is through forms of some sort. However, today's HTML forms blend the form's purpose with its presentation, are device and platform dependent, and do not integrate well with XML.
W3C is working on defining the next generation of forms, and calling it XForms (http://www.w3.org/MarkUp/Forms/). The biggest strength of XForms is the distillation of forms into three layers – purpose, presentation, and data.
The data layer refers to the instance data – an internal representation of the data mapped (using XPath) to the form controls.
The presentation layer is dependent on the client loading the XForms – this makes XForms device independent, and the same form can be rendered as HTML or WML, or sent to an audio device.
The XForms namespace defines elements such as <input>, <choices>, and <selectOne>; these are the basic constructs used in XForms – and define the purpose, with no reference to the presentation.
XForms 1.0 is a Last Call Working Draft, at http://www.w3.org/TR/xforms/.
XML Security Standards
When XML is used as the medium to perform business data transactions over the Internet, it becomes critical that the XML is secured: that data privacy and integration rules are met.
W3C has started three initiatives to create a robust mechanism to ensure data integrity and authentication for XML. These are XML Signature, XML Encryption, and the XML Key Management Specification (XKMS).
Out of the three initiatives outlined above, XML Signature is the most mature specification, and as of writing the only specification that has reached the Recommendation status. XML-Signature Syntax and Processing (http://www.w3.org/TR/xmldsig-core/) is a joint initiative between the IETF and W3C to outline the XML syntax and processing rules for creating and representing digital signatures. More details on XML Signatures can be found at http://www.w3.org/TR/xmldsig-core/.
The XML Encryption Syntax and Processing specification (http://www.w3.org/TR/xmlenc-core/) reached the W3C candidate recommendation status on March 4, 2002. This specification outlines the process for encrypting data and representing the result in XML. The result of encrypting data is an XML Encryption EncryptedData element, which contains (via its children's content) or identifies (via a URI reference) the cipher data. More details on XML Encryption can be found at http://www.w3.org/TR/xmlenc-core/.
XML Key Management Specification (XKMS)
XML Signature specification provides no means to properly validate the signer's identity before accepting a signed message. Similarly, when the encrypted message is received, XML Encryption specification does not provide anything to retrieve the encryption key. The Public-key infrastructure (PKI) can be helpful in such situations.
W3C has defined another specification, called XKMS, that specifies the protocols for distributing and registering public keys, suitable for use in conjunction with the XML Signature and XML Encryption standards. More details can be found at http://www.w3.org/TR/xkms/.
Visit http://www.xml.org/xml/resources_focus_security.shtml to get more information on XML Security standards.
Before delving deep into this section, let's consider a few facts:
Considering all the above facts, we can surely say that the combination of XML with HTTP (to begin with) makes a very interesting platform from which to build distributed applications that can run over the Internet and across platforms
- XML is plain text. It is license free. It is platform and language independent
- XML is a standard, and is widely implemented
- XML allows encapsulating structured data, and metadata
- XML is extensible
- HTTP is also widely accepted, very well implemented, and a standard protocol
- Most firewalls readily work with HTTP and have port 80 open
- HTTP is based on request-response model
- By adding 'S' to the end of HTTP, we make HTTP communication secure (using SSL)
- It is very difficult (if not impossible) to write distributed applications that can run over the Internet and across different platforms using proprietary technologies and messaging formats (DCOM, CORBA, RMI, etc.).
Dave Winer of UserLand Software, Inc. (www.userland.com) initiated talks with other industry experts (from DevelopMentor and Microsoft) about "remote procedure calls over the Internet". Not getting the expected response from Microsoft, Dave Winer went ahead and announced XML-RPC. The bottom line is that the XML-RPC specification allows software running on disparate systems to make procedure calls over the Internet, using HTTP as the transport and XML as the message encoding scheme. More details on XML-RPC can be found at http://www.xmlrpc.com.
The result of discussion between UserLand, DevelopMentor, Microsoft, and a few other organizations on the topic of building a platform-independent distributed systems architecture using XML and HTTP, SOAP was submitted for a W3C Note under the name of SOAP (for Simple Object Access Protocol), at http://www.w3.org/TR/SOAP/. Note that from SOAP 1.2, the term SOAP is no longer officially an acronym, although it originally stood for Simple Object Access Protocol.
The original name pretty much indicates SOAP's prime aims, namely to provide a simple and lightweight mechanism for exposing the functionality of objects in a decentralized, distributed environment. It is built on XML.
SOAP forms one of the foundation stones of XML Web Services. XML Web Services can be defined as loosely coupled software components that interact with one another dynamically via standard Internet technologies.
The SOAP specification uses the XML syntax to define the request and response message structure, known as the Envelope. With HTTP, the client POSTs the request envelope to the server, and in result gets a response envelop back.
Let's see an example of a SOAP request envelope to illustrate:
<?xml version="1.0" encoding="utf-8"?>
The above SOAP request envelope calls a method called GetAmazonPrice passing an ISBN as the parameter. When the above SOAP envelope is posted to the Web Service endpoint, the following response envelope is received in reply:
<?xml version="1.0" encoding="utf-8"?>
There are many toolkits available today that simplify SOAP development. Microsoft's SOAP Toolkit, at http://msdn.microsoft.com/soap, allows writing SOAP clients and servers, and in addition, allows COM components to be easily converted into SOAP servers that can then be used as Web Services.
The .NET Framework supports XML Web Services very well, and Web Services and clients can be created very easily in ASP.NET. In addition to the SOAP interface, Web Services created with .NET also support the regular HTTP GET and POST interfaces. Thus SOAP is not required to access the Web Service, and a regular HTTP GET or POST request can access the Web Service and retrieve the results as XML. We'll have a look at ASP.NET XML Web Services in a B2B context in Chapter 8.
The SOAP Toolkit and the .NET Framework implement SOAP 1.1. The current working draft of SOAP 1.2 is divided into three parts:
- SOAP 1.2 Part 0: Primer (http://www.w3.org/TR/soap12-part0/) is an easily readable tutorial on the features of SOAP version 1.2.
- SOAP 1.2 Part 1: Messaging Framework (http://www.w3.org/TR/soap12-part1/) describes the SOAP envelope and SOAP transport binding framework.
- SOAP 1.2 Part 2: Adjuncts (http://www.w3.org/TR/soap12-part2/) describes the RPC convention and encoding rules along with a concrete HTTP binding specification.
The Web Services Description Language (WSDL) is another important pillar in the XML Web Services architecture. It is an XML based format describing the complete set of interfaces exposed by a Web Service. As the component technologies (such as COM) make use of an IDL file to define the component interfaces, the XML Web Services make use of the WSDL file to define the set of operations and messages that can be sent to and received from a given Web Service. A WSDL document (.wsdl file) serves as a contract between clients and the server.
WSDL 1.1 is currently a W3C Note described at http://www.w3.org/TR/wsdl.
When an ASP.NET Web Service project is created using Visual Studio .NET, it automatically creates a WSDL file, and updates it automatically as Web Service methods are added or removed. A Web Service client can then access this .wsdl file (by selecting Project | Add Web Reference in Visual Studio .NET or by running wsdl.exe), and create a proxy class from it which allows them to access the Web Service's exposed methods (web methods). The WSDL documents created by Visual Studio .NET describe HTTP GET and POST based operations in addition to SOAP. This allows a client to access web methods by HTTP GET or POST request (application/x-www-form-urlencoded), instead of posting a SOAP request envelope. In addition to SOAP and HTTP GET/POST, the WSDL specification also permits a MIME binding.
The WSDL document can be divided into two main sections:
The <types> section contains the type definitions that may be used in the exchanged messages. The <messages> section represents an abstract definition of the data being transmitted. It contains one <message> element for each request and response message. Each <message> element in turn contains <part> elements describing argument and return values, and their types. The input and output <message> are clubbed together under an <operation> element, and all <operation> elements are placed under the <portType> element, which identifies the messages exposed by the Web Service.
- Abstract Definitions: Defines the SOAP messages without references to the site that processes them. Abstract definitions sections contain three sections, <types>, <messages>, and <portType>.
- Concrete Descriptions: Contains site-specific information, such as transport and encoding method. The Concrete Descriptions comprise two sections, <binding> and <service>
To map the above abstract definitions to physical concrete descriptions, we use the <binding> and <service> sections. The <binding> section specifies the physical bindings of each operation in the <portType> section. Web Services WSDL documents created with Visual Studio .NET contain three <binding> sections, for SOAP, HTTP GET, and HTTP POST. Finally, the <service> section is used to specify the port address (URL) for each binding. WSDL is described in detail in Chapter 8.
Universal Description, Discovery, and Integration (UDDI) offers three main operations:
publish, find, and bind. The notion behind UDDI is that it should be possible to dynamically locate businesses and businesses' Web Services, and bind to them so that they may be used in an application. The UDDI initiative outlines the specification and defines an API to perform these operations.
The UDDI registry is in public domain, and privately developed Web Services can be registered with the registrars. The links to version 1.0 of the IBM and Microsoft registry, and version 2.0 of the Hewlett- Packard, IBM, Microsoft, and SAP registries can be found at http://www.uddi.org/register.html.
Microsoft has released a UDDI SDK for the .NET Framework under the Software Development Kits hive at http://msdn.microsoft.com/downloads/. In addition, Microsoft .NET Server comes with UDDI Enterprise Server, which can be used to publish and find Web Services in an enterprise environment.
Direct Internet Message Encapsulation (DIME) is a specification submitted by Microsoft to the Internet Engineering Taskforce (IETF – see http://search.ietf.org/internet-drafts/draft-nielsen-dime-01.txt), and it defines a lightweight, binary message format that can be used to encapsulate one or more application- defined payloads of arbitrary type and size into a single message construct.
In other words, DIME can be used to send binary data with SOAP messaging, and it represents a very efficient means for transmitting multiple data objects (including binary) within a single SOAP message.
PocketSOAP (http://www.pocketsoap.com/) is one of the first SOAP Toolkits to support DIME. You can discuss DIME at http://discuss.develop.com/dime.html.
In October 2001, Microsoft announced the Global XML Web Services Architecture (GXA) set of specifications to add static and dynamic message routing support, and security facilities to XML Web Services. These are technically SOAP extensions under the following four categories:
In February 2002, Microsoft and IBM announced a joint initiative to promote Web Services interoperability, in the form of the Web Services Interpretability Organization (http://www.ws-i.org/).
At the time of writing, WS-I membership has grown to more than 100. The two primary goals of the organization are to promote Web Services interoperability across platforms, operating systems, and programming languages; and to provide guidance, best practices, tools, and resources for developing Web Services solutions, with the aim of accelerating the adoption of Web Services.
Representational State Transfer (or REST) is based on Roy Fielding's PhD dissertation (http://www.ebuilt.com/fielding/pubs/dissertation/top.htm), and is an architectural style that models system behavior for network-based applications. The idea behind REST is to describe the characteristics of the Web, with the aim of providing a model that can be exploited by developers
With this model, the traditional HTTP GET/POST URI-based model is used to create and access XML Web Services instead of SOAP. For instance, instead of posting a SOAP envelope request, we'll simply send a GET request containing method parameters in the querystring appended to the URL. We recieve the XML result without any SOAP packaging overhead. There is currently a little debate about what exactly SOAP adds, and if it isn't just a lot simpler to use existing web facilities (HTTP, GET, POST) for XML Web Services.
To keep abreast with REST, join the mailing list at http://groups.yahoo.com/group/rest-discuss/.
Hopefully this chapter has provided a good grounding in XML and its surrounding standards. We have talked about almost all key XML standards, current and future. We've seen that XML is much more than just a format for representing data, and there is a wealth of supporting technologies for common tasks with XML documents. As these technologies mature, third-party implementations arise to support them. If your core data is in XML, you may well be able to find an implementation that will let you do what you want in far fewer lines of code.
If you need to navigate a document, add to it, or change it in simple ways, there are at least two ways: the Document Object Model (DOM), a W3C Recommendation widely supported in code, and SAX, a de facto model also enjoying wide support. The .NET XML classes introduce yet another way to do the same thing, as we shall see in the next chapter.
XPath currently allows querying of an XML document. In the future XQuery will arrive, although software implementations are currently lacking. Visual rendering? Use XSLT to convert the XML into appropriate HTML and feed it to a web browser. Better still, there are a number of XML vocabularies for which native rendering code is available. In vector graphics, the SVG vocabulary is well supported by a free component from Adobe (http://www.adobe.com/svg). If you need mathematical formulae in text, you can encode your data in MathML and use one of several renderers for it (for example, Design Science's MathPlayer, http://www.dessci.com/webmath/mathplayer/). SMIL encodes multimedia, while VoiceXML covers voice response applications. ChemML is useful for visualizing chemical structures, and a viewer already exists for it. The list increases daily.
You can use the same technique, XSLT, to translate from one XML vocabulary to another. You can refer to one bit of XML from another using XPointer, XLink, or XInclude. Security issues are being addressed through XML signatures (http://www.w3.org/TR/xmldsig-core/) and XML encryption (http://www.w3.org/TR/xmlenc-core/). SOAP, as noted earlier, is an XML vocabulary, and all of the integration servers support XML as one of their primary formats. Messaging with Microsoft Message Queuing supports XML very well using features of the XML and MSMQ COM classes. Communications, therefore, should be easy
Once you have your native data in XML form, you are, to borrow a phrase, "halfway to anywhere". XML is such a useful format and enjoys such market penetration that software support is widely available for any commonly used XML technology. The W3C, among others, has extended XML in so many useful ways that you will find that many common and useful tasks can be readily performed using one of these technologies. The .NET classes provide built-in support for many of them. If you use XML, you will find that you can leverage this base of existing code and programming tools when building your web applications.
For a more in-depth discussion of XML and its related standards, take a look at Professional XML 2nd edition (Wrox Press, ISBN 1-86100-505-9).