he Web browser/Web server combination used today was originally designed to deliver HTML, which implicitly contains display information as well as data. But this doesn't mean that the Web server must
deliver HTML. When a page contains an <img>
element, or a hyperlink to a ZIP file, the Web server delivers the content in its native format. OK, so the content might be UU-encoded for transmission across the Internet, but it certainly isn't HTML when it arrives.
Delivering Simple Text Strings
As an example of a non-HTML information delivery, assume that a server uses one of the timeserver resources on the Internet to accurately maintain its internal clock. Therefore you can easily deliver the current time value from the server to any client upon request by generating a response containing the server's current time as a simple string. In ASP.NET, for example, you can use:
<%@Page Language="VB" %>
Response.ContentType = "text/html"
The data stream returned from the Web Server contains the usual HTTP headers required for communication between server and client, but the content of the returned "page" is just something like 10:25:07
. A Web browser will display this, but any other application that references the page can use the text string as required.
But the World Wants XML!
|Author's Note: Notice that the preceding code snippet sets the MIME type (using the ContentType property in ASP.NET) to tell the browser what to expect. The obvious choice is to use "text/text" as the MIME type value, but that confuses some browsers because they then try and use the file extension (.aspx) to decide what to do with the content. Using "text/html" effectively tells the browser just to display it, even though there are no <html> or <body> elements in the content. As you can see, the Internet provides everything required for the basic mechanism of making server calls and returning responses.
But simple text strings are not generally the most useful type of data. Looking at the issues in a more general way, what's really needed is a way of delivering information that:
- Has a structure defined through some universal standard
- Can represent complex data types, and not just simple string values
- Allows the recipient to identify the structure and data types within the content
- Supports validation of the content for both structure and permitted content
All these features have, in fact, long been on the agenda of both the Internet standards bodies (such as the W3C) and of those developers and corporations whose life revolves around data interchange. The result today is the evolving standards for Web services, as supported by most of the major players in the IT worldsuch as IBM, Microsoft and Sun. You can glean some idea of the huge amount of work going on in the Web services arena here
Delivering a DataSet
It goes without saying that the obvious choice of format for data exposed by a Web site or application is one that best suits the data itself. Anything much beyond a single value, such as a string, requires a data structure that can store multiple items; therefore some kind of rowset or recordset seems the ideal solution. The columns can contain items of different data types, such as integers, strings, real numbers, currency values, etc. There can also be one or more rows, providing the required flexibility for exposing all kinds of data.
For those of us who live in the Microsoft .NET world, the ideal container for a rowset is the .NET DataSet class. DataSets can contain one or more tables (rowsets), the metadata that defines features such as primary and foreign keys, default values, etc., and the relationships between the tables. The DataSet class is also optimized for reading and writing content as XML using Microsoft's proprietary diffgram
You can easily expose a DataSet object from a Web site or application using ASP.NET Web services, and thereby provide the best opportunity for any client to use the data in the way that they choose. And, best of all, clients that don't understand .NET and the DataSet diffgram format can still use the data by treating it as a "normal" XML document.