I just finished a whitepaper for the SQL Server team at Microsoft, my third of three in recent months. This one was interesting in that it ran counter, in my mind, to how Microsoft has been presenting SQL Server 2005 up to this point in its pre-release life. I’ve found that many of the cool, seemingly unrelated features are actually part of a very concious architecture they are positioning SQL Server 2005 for: data in an SOA world, what they are calling a Service-Oriented Data Architecture (SODA).
My assignment was to rewrite an academic paper into a whitepaper. The project was left relatively undefined for me, so I had a lot of leeway in how I approached it. That made for some fun, interesting explorations as well as not a little bit of stress in trying to make sure that I nailed it. Once I get the initial feedback from the SQL Server team I’ll know. <fingers crossed> And, of course, I’ll post the link when it goes live in a few weeks.
The original paper is by Microsoft’s David Campbell, “Service Oriented Database Architecture: App Server-Lite?," which he presented at the 2005 ACM SIGMOD International Conference on Management of Data and is a part of its Proceedings. The basic idea of the paper is that a database engine is a logical place to implement features that allow it to function as a full-fledge service program in an application based on SOA. There are three major functions that a service program has to implement to fulfill such a role:
- It has to support Web services (and other types of endpoints, but this is the most important and most common) so that it can process request and response messages with other components in the system.
- It needs the ability to process service requests, meaning that it has to be able to read and parse messages, which are most commonly XML. It also has to participate in complex dialogs and conversations, in the terminology of SOA.
- It has to host service logic, the ability to implement complex business logic.
This isn’t an exhaustive list by any means, of course, but provides the foundation for a database in an SOA environment, what Microsoft is calling a Service-Oriented Data Architecture. It turns out that this is a fascinating way to look at databases in distributed applications, and I had a good time exploring the possibilities in my whitepaper. It finally made sense why Microsoft put so much effort into implementing some of the features in SQL Server 2005, such as:
- Native Web Service Access. Combined with Windows Server 2003’s kernel mode http.sys driver that eliminates the need for IIS as a middleperson, SQL Server has a very efficient way to receive and send SOA messages.
- Service Broker, the new transactional middleware that supports massively scalable services. This is the best example of the synergy of implementing such a feature in SQL Server itself—and the database engine—rather than merely integrating with other technologies such as Microsoft’s own MSMQ. After all, messages are “interesting data.”
- Notification Services, the SQL Server name for what other platforms call database change notifications. Unlike client-server and n-tier applications that use a highly centralized data store, SOA applications are likely to have data all over the place, some of which is cached from various sources. Those caches need an efficient way of knowing when to refresh themselves, and notifications provide that way. Notification Services isn’t just for sending messages to a PDA anymore, and I’m intrigued by the possibilities.
- SQLCLR, the linchpin that makes it all possible. To be a viable service program requires complex business logic, and T-SQL, extended stored procedures, and OLE automation (COM) just don’t cut the mustard. Hosting the .NET Common Language Runtime in SQL Server is simply a stroke of genius.
SODA is a compelling vision for SQL Server, one that I’m looking forward to exploring further in the coming months. It certainly explains many of the new features that SQL Server 2005 sports, something that I had been a bit confused about. I mean, Service Broker doesn’t exactly duplicate MSMQ—not even close—but why not build on MSMQ rather than start anew (regardless of whether they used the MSMQ codebase)? And hosting the SQLCLR makes for some nifty possibilities for server code, but up to now Microsoft has talked mostly about it being a replacement for extended stored procedures, not T-SQL stored procedures. Most articles and papers on the topic seem to conclude with a caution that .NET code shouldn’t replace regular stored procedures. So until SODA I didn’t appreciate the value of hosting the CLR in SQL Server.
This raises the question: Why has Microsoft not been talking about SODA? The original SODA paper was presented at an academic conference, not the sort of thing where working developers or DBAs would hear about it. I searched for more information about it but found precious little. Until they asked me to do the whitepaper, there was really nothing out there in the Microsoft space. I can’t imagine that they’d be trying to downplay this close connection with the buzzword-enhance world of SOA. Would they? If not, then why?
Alas, I’ve learned through years of training and writing not to attempt to handle Why questions about Microsoft. Too often I’ve either found that I didn’t like the answer or that there just wasn’t an answer. Heh.
Anyway, my advice is to start looking at SQL Server 2005 in this new holistic way as its place in the SOA world. There are a lot of very interesting possibilities and I, for one, am hoping that the vision pans out. So far, the future of SODA is looking very promising indeed.