XML and the Database Developer

You're a SQL Server developer responsible for building your company's new Web architecture. You're magically transported through time to exactly one year from today and your boss asks, "Do you know enough XML to get the job done? How does XML fit into our design?" In other words, is XML really that important to the life of a database-oriented application developer?

I'm a database geek. I'd love to be an expert in everything, but unfortunately there's not enough room in my brain for everything I'd like to know about SQL Server. So, unless it's hardcore SQL Server, I rarely have time to drill beyond the level of knowledge that lets me to draw pretty pictures on the whiteboard during an architectural planning session. Lately I've been struggling with how much of my limited brainpower should be devoted to learning XML. Unless you live under a rock, you've noticed that XML has been getting a lot of attention. On a scale of 1 to 10, with 9 being the wheel and 10 being the opposable thumb, many people have been ranking XML as an 11. Read too many articles and you might begin weeping with joy, convinced that XML will solve every woe the computer industry has ever or will ever face.

So back to the real question. As a database professional, how much time should you spend learning XML? Fundamentally, XML is really "nothing but data," which is what a database is all about, right? I started to think about how XML will affect my day-to-day life as a database architect and began with the fundamental belief that XML would change everything I do. After all, that's what all the experts are saying and who am I to argue? Don't flame me for being stupid until you've read the rest of this article, but I've started to believe that knowing XML won't be all that important from the perspective of the application developer responsible for interacting with the database.

Like many of you, I was super excited about SQL Server 2000's "tight integration" with XML, and I figured that I should be spending a bunch of R&D time mastering SQL Server's XML extensions. I'm going to make some gross oversimplifications but, unfortunately, I was disappointed when I started to drill down into SQL Server 2000's XML offerings. I'll go so far as to say that no sane person would want to base their application architectures on SQL Server's current 'native' support for XML delivered through native http interfaces. I don't have space to fully explain or fully defend that belief, but I've spoken with enough of my colleagues to convince myself that I'm not entirely off base with that opinion. I started to worry that SQL Server might not play well in the e-world of XML, but then I started reading about .NET and ADO+ and felt much better.

ADO+ is a core part of Microsoft's new .NET framework, and it will be the primary way we interact with data when building Microsoft-based solutions in the very near future. Today, developers have to make hard choices when deciding to use the MDAC or MSXML data stack to manage data in their applications. Sure, current versions of ADO have some basic support for XML, but in many ways it was tacked on as an afterthought. ADO+, on the other hand, has been built from the ground up to treat XML as a first-class citizen in the world of data management, letting us use MDAC and MSXML technologies in complementary manners. In fact, disconnected datasets in ADO+ are persisted natively as XML with relevant schema information so applications can understand how to interact with the data. In other words, ADO+ datasets are essentially just XML. But you'll need to know little (or nothing) about XML to use them.

Yes, baking XML deep into the .NET infrastructure will let us do a number of really cool things. Yes, XML is a tremendously important technology. But should application and database architects use their limited brain space learning how XML interacts natively with SQL Server or should they spend their time learning ADO+ inside and out? Time will tell, but I'm putting my money on ADO+. Today, most of the world talks to SQL Server database through ADO. Tomorrow, most of the world will talk to SQL Server through ADO+. XML might be flung back and forth across the wire, but understanding ADO+ is where the real action will be. Microsoft is shipping a public beta of VS.NET and the .NET Framework. Take some time, find a spare machine, and start digging into ADO+. You'll find download links for both betas at the MSDN .NET Developer Center, plus a number of valuable MSDN articles including "Introducing ADO+: Data Access Services for the Microsoft .NET Framework."

If you really have your heart set on mastering SQL Server 2000'scurrent XML capabilities, you'll want to read "SQL Server XML and WebApplication Architecture." This article provides an overview of the resulting architectures when both the Duwamish Books, Phase 4 application, and the more robust Duwamish Online application were applied in a set of SQL Server XML-based solutions. You can find the article on MSDN's Web site.