Don Kiely's Technical Blatherings : SQL Server 2005: Foundation of Service-Oriented Data Architecture

Link

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.