XML.com 
 Published on XML.com http://www.xml.com/pub/a/2004/05/12/dotnet.html
See this if you're having trouble printing code examples

 

Document-Centric .NET
By Eric Gropp
May 12, 2004

The principle "program to an interface, not an implementation" helps control the complexity and enhance the flexibility of systems. XML interfaces are a natural extension of this principle that bring a number of new benefits in terms of flexibility, reusability, simplified code, and readiness for enterprise environments.

We will walk through a sample application to see how the .NET framework classes can work together in an application centered around an XML interface. This XML interface will be the hub of present and future requirements. Our application will produce a bar graph from a variety of data sources. Though this example is relatively trivial, similar approaches can solve larger and more complex problems.

The Schema

Our bar graph application will revolve around a schema written in the W3C XML Schema language. Specifying this schema will be one of the first and most important design steps. Stability is key and all the better if you can use a standardized schema for your application. However, keep in mind that there are W3C XML Schema features that are not directly compatible with .NET's XML-to-database and XML-to-object mapping tools.

Flow of our example document centric application

For this application we'll use a custom schema: BarGraph.xsd. An instance document conforming to this schema looks like the following:

<BarGraph xmlns="http://example.org/bargraph">
  <Bar>
    <Title>Portland</Title>
    <Value>32</Value>
  </Bar>
  <Bar>
    <Title>Berlin</Title>
    <Value>20</Value>
  </Bar>
  <Bar>
    <Title>Pune</Title>
    <Value>16</Value>
  </Bar>
</BarGraph>

Taming the Winds: Input into our Application

We'll start by gathering input from a variety of sources. The following three examples will each produce the same result: an XmlReader containing bar graph XML. XmlReader is an abstract class that plays a similar role to other platforms' use of SAX, in that it can be used to pass the contents of a XML text file, a DOM tree, or a high-throughput dynamic data source.

GetXml() #1: REST web service

The most familiar benefit of XML interfaces is that they allow applications to span machine and platform boundaries. Techniques that are well described asREST can be an easy way to pull XML from a network resource.

GetXml() #2: Database

Another data source might be a database. Microsoft has placed XML at the center of its ADO.NET data access library with the DataSet, which is simultaneously a disconnected set of relational data and a XML document.

GetXml() #3: User Form

The previous example showed how a DataSet object can be used as a bridge between a database and XML. The DataSet can also be used as a bridge between controls in a Windows form and XML. The complete source code for this example is at form2graph.zip.

Application Output

Each of the following examples will perform some action using an XmlReader containing bar graph XML. Naturally the choice of our input source is unimportant, since all the sources produce XmlReaders conforming to the same schema.

OutputAction() #1: An SVG Image

Another familiar benefit of XML interfaces is that an SVG or XHTML presentation is often only a transformation away.

OutputAction() #2: A PNG Bitmap

If some sort of human analysis is required, it's more appropriate to work with a graph than XML. This is how we'll convert our bar graph XML into a PNG image file. The complete source code for this example is in graph2png.zip.

OutputAction() #3: A Network XML Consumer

Perhaps our application is just part of a distributed pipeline or needs to pass the bar graph XML into some sort of content management store. Here we'll pass the bar graph XML on to a protected REST webservice.

Conclusion

This architecture is not for everybody. For some, the approach will place unwelcome constraints on W3C XML Schema and class design. Also throughput and security considerations may make it inappropriate for some applications.

However, for applications that live in dynamic environments, you achieve true loose coupling of components with all the flexibility of XML. An XmlReader producing and consuming components of your application can be readily swapped out, improved, or reused by other applications or pipelines. It also reduces the amount of wiring required to tie components together.

More tools are on the way for XML-centric applications in the upcoming versions of .NET and Windows, named Whidbey and Longhorn respectively. .Net brings XQuery Support and the new XmlReader and XmlWriter implementations ObjectReader and ObjectWriter, providing additional support for serializing and deserializing objects. Longhorn's XAML, which uses XML to define windows UI elements, can make interface elements a transformation away from your data or schema XML.

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.