Guest Opinion
Data: Now and Future
By Dave Reed
The majority of computer-related technology discussions these days are motivated by the Internet. A discussion on data access is no exception. Computers have become increasingly interconnected through Web Services and the Internet, and one result of this is the volume of data being transferred, manipulated, transformed, and persisted. For example, reading a purchase order off the wire then processing and persisting it touch many parts of XML and relational data access. Rich data access must be pretty important, right? You bet!
Data access has a whole host of issues developers must grapple with. How can you squeeze the last bit of performance out of a data-intensive application? How do you get large datasets to the client? Should you cache data on the client? You also can choose a data-access API, and once that choice is made, what are the abstractions and how are they used?
As a developer, you likely have encountered these and other questions around data access, and you might have done it multiple times in your career as you make transitions from technology sets. We are in the middle of such a transition right now as developers migrate to the .NET Framework.
At Microsoft, we worked tirelessly to make data access in the .NET Framework rich and applicable to modern application scenarios. Some guiding principles in building the .NET Framework included striving to find the right factoring. Instead of building an uber-object to perform several tasks, we built several abstractions, each tailored for a specific purpose. We wanted to build powerful abstractions for both XML and rowset manipulation and share a common architecture between these two worlds. For example, consider the XMLReader and DataReader interfaces. Once you understand the Reader architecture, you see similar patterns between the XML and relational worlds. In subsequent releases, you'll see an even broader architecture shared by the two worlds, which will help developer learning.
Are XML and relational data access the only access mechanisms? Today, yes. Tomorrow, however, we'll add objects to the list. Object access will enable you to work with a strongly typed representation of your back-end data, whether that data is relational or XML. Object-based data access will share a common architecture with the XML and relational mechanisms, along with corresponding abstractions. Object-based access will be a natural addition to the .NET Framework, providing you additional flexibility in your choice of access style. I've found two types of developers in the world: those who want to think in terms of objects, and those who want to think in terms of the underlying XML or relational data model. Microsoft's vision is to provide both.
One problem when introducing any new technology is knowledge transfer. When faced with a new API set, developers have a difficult time determining when to use what and where. In the .NET Framework, we have worked to make the choices as prescriptive as possible, but we still can do better. We've delivered rich samples, written articles, stayed active on newsgroups, and have had a presence at conferences such as the ASP.NET and XML Web Services Solutions. But there is more to do, and you should expect to see a lot of activity in this area in the coming months.
The world of data access has changed dramatically in the past couple years. Mostly driven by Web Services and the Internet, developers are working more and more with XML in addition to relational access. Release 1 of the .NET Framework was built to address this new world, with XML at the core. Moving forward, we are paying close attention to the development community and its experiences around building distributed, Web-based applications. Microsoft is involved in standards emerging in the XML space, such as the WC3 XQuery specification, and we believe we have built a solid base with the .NET Framework and look forward to your input and continued support.
As Microsoft's general manager of XML and data technologies, Dave Reed runs the SQL Server group's Web data team. He's driving the direction of XML and data access, including ADO.NET, MSXML, System.XML, ODBC, OLE DB, MDAC, and the SOAP Toolkit. Dave also was on the original development team of Microsoft Transaction Server (MTS).
