By Kraig Brockschmidt and Lorenz Prem, Program Managers,Microsoft Corporation

Last updated September2010

Over the last twenty years, Microsoft has been developingever-more powerful and flexible data access solutions. Some are veryspecialized, others are general-purpose, but all of them share two commongoals: to help applications get at the information they need and to helpdevelopers spend less time dealing with intricate details of data storage andmore time creating sophisticated software that utilizes that data for real benefitsto their customers.

In this historical overview, you’ll quickly see that thereare as many different data development technologies as there are differenttypes of data sources. Some technologies have been retired, but most of themare still active and more keep being developed. Why is that? Why does Microsoftkeep creating additional ways to do essentially the same thing?

The most central reason really has nothing to with theparticulars of accessing or manipulating data, nor even the particulars ofdatabases. Fundamentally, it has to do with the fact that the most long-lastingelement in nearly all computer systems is data.Not the hardware, not the design architectures, not the database technology nordata access APIs, and certainly not the applications that are built on dataaccess technologies.

No, data outlives themall, because it’s data that essentially holds the facts of our existence—aspeople, organizations, and nations—and as such those facts will remain factsforever. Sure, such data gets migrated from one system to another (and another,and another). And maybe it gets updated on occasion, as when someone is born,when someone changes their name, or when we discover that we really should haveused four digits to store a year rather than two. But so far as computersystems are concerned, data is effectively immortal, and everything else is buta wrapper. Systems may be upgraded or fall into obsolescence, and perhaps onedatabase vendor makes a better sales pitch than the competition. Whatever thecase, data gets moved around all the time…and yet the data itself stays thesame and is still there waiting to be accessed and put to good use.

Every layer, then, that is built up around the data isincreasingly more ephemeral—that is, shorter-lived—than those closer in. Datahas more longevity than the database engine, which in turn generally outlivesdata access technologies. As you read this article, for example, note theconstancy of the Microsoft SQL Server box in the illustrations: it stays whereit is in the lower right corner, outliving its original data accesstechnologies as it will likely outlive current ones and even those that arejust now in development.

Of course, those data access technologies in turn outlivespecific applications built on top of them. Another way of saying this is thatspecific data access technologies serve a particular means of building applications—such as unmanaged Win32 code ormanaged .NET code—or a particulate type of application—such as rich client, webapplication, or server application. So they naturally have a longer lifespanthan any given application (just as applications have a longer lifespan thanthe forms they present to the user which easily change from version toversion).

Data access technologies come, and occasionally go, simplybecause they each accommodate the development needs around different kinds ofapplications and different kinds of data stores. This is why there aretechnologies for managed (.NET) and unmanaged (Win32) code, and technologies thataccommodate applications wanting to be database-agnostic as well as thosewanting to optimize for a particular source. It's really just a matter offinding which method best fits your particular requirements. (For a conciseselection guide across all presently-supported technologies, see the Learn page on the Data Developer Center.)

Along with the data access technologies support servicesstarted appearing. Every company, it seems, requires reporting, analysis, andother services to run on the data contain in the databases deployed throughout theenterprise. At first these support features did not exist, or existed in a verylimited fashion. As time progressed they improved. Along with them the valuethat could be derived from data stored in database grew. The data will outlivethese services as well, but these services will continue to add more and morevalue to the database model.

A Brief Nod to Microsoft Access

In the early 1990s, Microsoft had two primary databaseofferings: SQL Server and Access. Microsoft Access, for its part, was andremains a fabulous combination of a database engine and a front-end designenvironment, allowing rapid development of complete database applicationswithout traditional coding practices. But that’s as much as we’ll say about Accesshere, because with a solution like Access you really don’t need to concernyourself with the mechanics of talking to a database. Access does that underthe covers. What’s more, as a desktop client solution, Access only targets aportion of the database applications people want to create; many applications do need to concern themselves withgetting to the data directly.

This was true with SQL Server from the beginning, which initself was all about high-performance data access suitable for large numbers ofconcurrent users. Its focus was on serving up the data to whatever applicationswanted to get at it, however those applications were written. In that sense,little has changed over the years except that the landscape of data sources ismuch more expansive, the types of database applications are much more varied,and the means of the latter talking to the former have been constantly built up,just as a small community with a couple of houses grows and matures into afull-fledged township. And it’s this particular story of growth that puts allof Microsoft’s data development technologies into context.

The Foundations of Data Development: Win32 ("Native")Technologies

When Microsoft first introduced SQL Server 1.0 in 1989,there was a single programmatic or “call-level” API called DB-Library. Through its 150 functions, an MS-DOS or OS/2 consoleapplication or a Windows or OS/2 GUI application could party on data with thecreate-retrieve-update-delete operations we still know and love today(ironically referred to with the wonderful acronym of CRUD).

Also available was EmbeddedSQL for C (ESQL for C in its short form), a precompiler that allowed SQLstatements directly in source code, a simple foreshadowing of what we’ll seelater in LINQ. (If you’re interested, a basic piece of ESQL for C code can befound in the SQL Server2000 documentation.)

At this point in time, other databases had their ownproprietary APIs like DB-Library, but all of these were completely separate asshown in Figure 1.

Figure 1: Data access technologies circa 1990; Microsoft’s offeringswere only those for SQL Server.

In September 1992, Microsoft Released the Open Database Connectivity specification orODBC. ODBC, still in widespread use, is a 50-function call-level API thatcommunicates through drivers to any number of underlying databases ordatabase-like stores. ODBC builds a data access abstraction on top ofproprietary APIs, giving applications a single means to get to a wide varietyof data sources from the oldest legacy dinosaur to the latest cutting-edgetechnology. Database vendors, if they choose, can also supply a native (thatis, no-middlemen) ODBC driver to achieve better performance (as Microsoft doeswith SQL Server).

Applications, of course, are still free to use proprietaryAPIs; ODBC simply provided a way for applications to isolate themselves fromsuch APIs, as when those applications needed to operate against multipledatabases from different vendors.

Figure 2: Data access technologies in September 1992.

A few years later, as object technologies and programminglanguages (such as COM, C++, and Visual Basic) came into the mainstream, newobject-oriented access layers were created. First came Data Access Objects (DAO) in Visual Basic 3 (November 1992). Thiswas later replaced in Visual Basic version 4 August 1995) with Remote Data Objects (RDO), aVB-compatible object layer on top of ODBC. A year later in August 1996,Microsoft released the much more generalized OLE DB technology to create an object-oriented access layer alongside ODBC, working again on a datastore-specific provider model.

OLE DB, which is also still in widespread use, doesn’t raisethe level of abstraction for data access above that of ODBC; it simply providesa programming model that's suitable to certain development styles. Still, atthe time it was released it also helped open up even more types of data stores,specifically those that could be represented as tabular data (such asspreadsheets and text files). In that way OLE DB was an advance from OBDC.

Figure 3: Data access technologies in August 1996.

Of course, by this time the Internet had already begun itsrapid expansion, and with it came the importance of web applications alongsidedesktop client applications. OLE DB, however, is oriented aroundpointer-capable languages like C and C++, which means scripting languages likeVBScript and JavaScript, that do not support the concept of pointers, are leftbehind. So it was necessary to introduce a suitable technology that allows webapplications to access to the vast array of data stores for which OLE DBdrivers are available.

The result was ActiveXData Object, or ADO, a higher-level object abstraction built on top of OLEDB, available to pointer-capable and pointerless programming languages alike. ADOwas first released in October 1996 (and had thus obviously been in developmentfor some time along with OLE DB).

Figure 4: Data Access in October 1996.

There were then six different Microsoft APIs for data accessdepending on how an application was written and the kinds of data stores itwanted to access:

Since that time, many of these technologies have lived on asdependable workhorses that continue to support the many kinds of applicationsthat developers need to create. Some improvements have been introduced, and someolder technologies have been retired as newer ones have come in to fill thesame needs. Support for DB-Library ended with SQL Server 2000, for example, asa new and better direct API, SQL Server Native Client, wasintroduced with SQL Server 2005. Similarly, the development ofLanguage-Integrated Query (LINQ) ended the long run of ESQL for C with SQLServer 2008.

RDO, similarly, was supported through Visual Basic version6, after which Visual Basic became Visual Basic .NET and the focus shifted toADO.NET (as we'll see in the next section).

Indeed, the introduction of the .NET Framework (version 1.0in February 2002 and 1.1 in April 2003), has shifted the primary focus of most newdevelopment efforts into the managed-code space. Thus while the ODBC, OLE DB,and ADO technologies continue to age, they remain the primary data accesstechnologies for unmanaged code (i.e. Win32) applications. Today they arecollectively known as the MicrosoftData Access Components (MDAC) or the Windows Data Access Components (WDAC),and are part of the Windows SDK.

There is also some continued evolution in thesetechnologies, such as ADO Multi-Dimensional(ADOMD), ADO Extensions for DDL andSecurity (ADOX), the SQL Server Java Database Connectivity (JDBC) driver, and the PHP driver for SQL Server. See Figure 5 and the table thatfollows it. In short, with or without the .NET Framework, there is still anongoing need for direct, optimized access to data stores like SQL Server fromunmanaged code environments.

For more information on these, visit the links above as wellas the SQL Server Developer's Centerand the Data Access TechnologiesRoad Map [up to ADO.NET]. A similar article to the latter is Data AccessTechnologies, which again is primarily focused on these Win32 technologies.

And with that we’ll leave the unmanaged code realm and shiftour focus as well to developments in the kingdom of .NET.

Figure 5: Data Access Technologies for Unmanaged Code, current to September2010.

Data Development Today, Part 1: Direct Data Access

The introduction of the .NET Framework in all its glorymight have changed the way applications were developed and the tools used todevelop them, but it did not change the fundamental need for applications toaccess data. Indeed, the introduction of the .NET Framework and the developmentof .NET data access technologies further demonstrate the underlying longevityof data and of the database technologies used to store that data, neither ofwhich changes with .NET.

According to its basic design, the .NET solution to anyprogramming need is to supply appropriate .NET classes with the desired APIs.In the case of data access, primary classes include SqlConnection, SqlCommand, DataReader, DataSet, and DataTable (along with server controlsfor ASP.NET applications). Such classes together compose the core of ADO.NET.

ADO.NET is basically the .NET sibling to ADO, exposing asimilar conceptual model while also offering expanded capabilities. For acomparison of the two technologies, see ADO.NET for theADO Programmer. (Even if your only knowledge of ADO comes from this presentarticle, the comparison still provides an excellent overview of ADO.NET in itsown right.)

Like its predecessor technologies, ADO.NET works through anabstraction layer that hides the details of the underlying storage technology. Thatlayer is provided by ADO.NET “data providers,” and Microsoft supplies a nativeprovider for SQL Server as well as providers for OLEDB, and ODBC (see .NETFramework Data Providers in the .NET 1.1 documentation). What’s more, ADO.NETsupports transparent access to XML sources in the same manner (something ADOdid not do). These relationships are illustrated in Figure 6. (Note: for a morecomprehensive version of this diagram, see the .NET Data AccessArchitecture Guide article. Also note that while the DataSet class is part of the .NET System.Data assembly, DataReader and DataAdapter are implemented by providers, as are provider-specificclasses like SqlConnection and SqlCommand.)

Figure 6: The introduction of ADO.NET in 2002/2003.

This view of data access through ADO.NET still remainscurrent today, and the majority of .NET applications are actively using the DataSet class (and related classes like DataAdapter and SqlCommand) to talk to their underlying data stores. (For detailson the differences between ADO.NET in the .NET frameworks version 1 and 2.0,refer to What’sNew in ADO.NET [.NET Framework 2.0]).

Now it’s important to point out, as a prelude to the latesttechnologies, that the basic data access programming (that is, querying) modelin ADO.NET is pretty much the same as we’ve known since the beginning of thishistory:

1. Open a database connection
2. Execute a query in the database
3. Get back a set of results
4. Process those results
5. Release the results
6. Close the connection

(As an example, compare the structure of the basic DB-Librarycode in the SQL Server 2000 documentation and that of the basic ADO.NETcode available in the All-In-One CodeFramework, specifically the project called CSUseADONET and the code paththrough the SelectUsingUntypedDataSetmethod).

In other words, while the APIs and other details havechanged throughout the years, the essential structure of the code has remainedthe same. This is not a bad thing, because this programming model clearlymatches the basic purpose of databases: to ask questions and get back answers.It would be a safe bet, in fact, that whenever a new general-purposedevelopment environment comes along (on the order of the .NET Framework), therewill be new data access technologies that follows this model. In the meantime,ADO.NET will continue to be a core means of data access.

But there is still plenty of interesting things to do wheredata access is concerned. In fact, two of the most interesting technologies, Language-Integrated Query (LINQ) andthe ADO.NET Entity Framework, wereintroduced with the .NET Framework version 3.5 and version 3.5 SP1,respectively. In many ways these technologies are much more significant stridesthan the transition from ADO to ADO.NET.

Introduced in November 2007, LINQ keeps alive the ghost of ESQL for C: the idea of embedding queriesdirectly within the structure of a programming language itself. As evidenced inits overview,LINQ is a far, far better solution than its distant ancestor in these ways:

• LINQ can be used from any .NET language thatsupports it (like C# and Visual Basic)
• LINQ allows for many modern performanceoptimizations
• LINQ can operate against (that is, query andupdate) arbitrary data sources

Those data sources can be anything from in-memory CLRobjects to XML to databases to ADO.NET DataSets to any other source upon which someonehappens to implement a .NET class with theIEnumerable or IQueryable interfaces. These are shown in Figure 7.

Figure 7: The introduction of LINQ in November 2007 including LINQ toObjects,
LINQ to XML, LINQ to DataSet, and LINQ to SQL.

It shouldn’t be surprising, then, that there are not only ahealthy handful of “LINQ to XYZ” implementations that Microsoft provides, butthere are literally dozens of third-party implementations including things likeLINQ to Flickr, LINQ to Amazon, LINQ to CSV, LINQ to MAPI, and LINQ to Twitter.In short, if something can look like a queryable data store, you can put an IQueryable interface on it and make itwork with LINQ.

The other recent development in data access takes even anotherstep beyond LINQ. That is, while LINQ introduces a remarkably simple yet powerfulquery mechanism, especially in working with DataSetand SQL Server databases, it doesn’t change the essential nature of how the application sees relational data.Every technology for relational data that we’ve seen so far, in fact—DB-Library,ESQL for C, OBDC, OLEDB, ADO, ADO.NET, and LINQ—are all united in that they inherentlywork directly against the relational structure of database tables.

This is all well and good for simple databases and simpleapplications. However, as a database gets richer and an application moresophisticated, we see increasing divergence between the way an applicationneeds to look at the data—its “conceptual” or “object” model—and the wayinformation is structured in the database—the “storage” or “relational” model.”A manufacturer's ordering system, for example, may store its order informationin multiple related tables, yet the application programmer really wants to workwith a single, conceptual “order” entity without having to do a complex JOIN inevery order-related query. (This is a case of what’s called the“object-relational impedance mismatch,” if you’ve heard that term.)

For this reason, programmers have routinely implemented theirown mapping layers to create those singular, conceptual entities. Such a layer suppliesa single “Order” object, for example, with methods like Retrieve and Updatethat internally perform the necessary database-level queries to shuttleinformation between the Order object and the underlying tables.

Mapping layers, in short, conveniently isolate theapplication from the specifics of the logical database structures. It’s a verycommon pattern that one can find in projects written from DB Library to ADO.NETand LINQ to SQL. What’s not so convenient is that these layers are tedious toimplement and maintain.

That changes with the EntityFramework introduced in August 2008 with the .NET Framework version 3.5SP1 (see overview) and greatly improved with the .NET Framework 4in April 2010. The Entity Framework, as it’s simply called,automatically generates a mapping layer of .NET classes from an existingdatabase, along with a concise textual description of the mapping between conceptualand relational levels, which you can customize however you like. Whatever thecase, the Entity Framework provides full LINQ access to the resulting entities(LINQ to Entities), and as it’s built on top of ADO.NET the Entity Frameworkdirectly leverages the ADO.NET providers.

That conceptual and relational representations can be easilycreated using designers in Visual Studio, and the Entity Framework designer inVisual Studio will create a default mapping without any effort on your part. Inother words, don't think that working with the Entity Framework introduces morecomplexity than other solutions—it is, in fact, easier than everything else forcore scenarios and offers much more flexibility beyond the basics. And thebottom line of it all is that you can focus your efforts on what you reallycare about—the conceptual objects and mapping—and not labor over all the tedious,error-prone plumbing code that’s traditionally left to summer interns.

This brings us to the current state of the art as of September2010 as shown in Figure 8.

Figure 8: The Entity Framework, first released in August 2008, automatesthe hard work of conceptual mapping. An Entity Data Model is used at compiletime to generate classes for a mapping layer.

Data Development Today, Part 2: Data in the Cloud

As subtly betrayed by the title of the last section,everything we’ve seen to this point applies primarily to applications that canaccess a database in some direct manner, such as the file system, named pipes,etc. This applies to client applications accessing databases on an intranet aswell as web applications accessing backing stores on their web servers (and webapplications written in ASP.NET have full access to ADO.NET and EntityFramework, of course).

What we haven’t talked about are applications that accessdata more indirectly, such as web or rich internet applications that wish tocreate and consume REST-based data services.

To be honest, this subject starts to bridge us into theworld of the Windows Communication Foundation (WCF) and the world of webservices in general, which goes beyond the scope of this article. We mentionit, however, to introduce WCF Data Services (formerly ADO.NET DataServices and code name “Astoria”), a framework that facilitates thiscommunication behind the scenes of what we’ve been exploring so far (see Figure9).

Figure 9: WCF Data Services facilitates creating and consuming
REST-based data services.

The goal of Data Services is to facilitate near-turnkeycreation of flexible data services that are naturally integrated with the web,using URIs to point to pieces of data (such as entities in an Entity Data Model)and simple, well-known formats to represent that data (such as JSON and XML).Other web applications (and agents) can interact with the resulting REST-styleresource collection using the usual HTTP verbs such as GET, POST, or DELETE.Indeed, so universal are the conventions for working with data services thatthey have been formalized as the Open Data Protocol, information on which canbe found at www.odata.org.

Many of the Microsoft cloud data services, such as WindowsAzure tables, SQL Data Services, and SharePoint, expose data using the DataServices protocol. This means that the Data Services client libraries anddeveloper tools can be used to work with both on-premise and hosted cloudservices.

Data Development Futures

If we take a step back from the whole arc of the discussionwe’ve had in this article, we can see a definite trend toward greater levels ofabstraction. The earliest data access solutions for SQL Server, like DB-Libraryand ESQL for C, were sufficient though quite rudimentary. Technologies likeODBC created an abstraction layer above the proprietary APIs of differentdatabases, a model that OLE DB, ADO, and ADO.NET continue to follow.

Most recently, the Entity Framework has gone a step furtherto create an additional abstraction layer not over the data access API but overthe structure of a relational database itself. Similarly, Data Servicestransform any number of diverse data sources into something accessible through asimple REST-based exchange protocol, the Open Data Protocol or OData (see http://www.odata.org). In fact, Microsoft expectsthat using such protocols will become increasingly popular, as it allows dataproviders and consumers to evolve independently from their programming model.

Microsoft is continuing to evolve both the Entity Frameworkand WCF Data Services and the Open Data Protocol. These are the areas that willsee continued investment. For more information, see Entity Framework futures and Data Services futures.

Application Services in Microsoft SQL Server

Soon after thelaunch of the first database it became apparent that users wanted to do morewith the data than just read and write it. Data has the wonderful property ofbegin useful in many scenarios besides the one for which it was originallycreated. Users wanted to gather it, transform it, analyze it, and makedecisions based on it. To address these needs Microsoft started development onmany value-add application services based on SQL Server.

To begin with, DataTransformation Services (DTS) was introduced with SQL Server 7.0 in 1998 as anapplication model for data transformations that run on the database server.Developers could define application packages that contain data transformationlogic. Packages were triggered by events in the database. DTS was viewed as asignificant improvement to the client-application-only model that existedbefore. DTS is the right choice for workflow like apps that are triggered bydatabase changes.

Asshown in Figure 11, SQL Server 7.0 also included another new data service, theOnline Analytical Processing (OLAP) services. OLAP analysis is a method foranswering multidimensional queries, which are an important tool in dataanalysis. The OLAP service marks the beginning of business intelligence basedon data stored in a SQL Server at Microsoft (and is now known as SQL ServerAnalysis Services as noted below).

Figure 11: Thefirst introduction of support services for SQL Server in SQL Server 7.0 (1998)

SQLServer 2000 saw the addition of SQL Server Replication Services (Figure 12).This featured made it possible to take data stored in one database andreplicate it in another. The database moved one step closer to becoming thesource of all data in the enterprise. Since the 2000 release SQL Server canimport and export data from and to other databases. In most cases the data canbe kept in a consistent state automatically. Developers should note thatmanaging data consistency is best achieved using the replication servicesinstead of doing the work at the app level.

InSQL Server 2000, OLAP was also renamed to SQL Server Analysis Services, reflectingthe addition of data mining and other features that go far beyond thedefinition of OLAP. The data gathered by the service can be accessedprogrammatically. The SSAS API exposes essential data analysis features.

In2000 the database also extended to client devices. Windows Compact Edition (CE)was released along with a lightweight database engine. Today this engine isknown as SQL Server Compact Edition. The database runs on lightweight clientdevices such as cell phones and pocket PCs. Mobile application developers canaccess the benefits of the database programming model along with its ecosystemof value-added services.

Figure 12:Replication Services and SQL Server Compact Edition were introduced with SQLServer 2000. Analysis Services also absorbed OLAP and added new features suchas data mining, leading to the new name.

In2004 SQL Server Reporting Services (SSRS) was released as an add-on for SQLServer 2000. Companies demand reporting capabilities on the data and data-relatedevents stored in their databases. Design as a business intelligence tool, SSRSbridged the gap from data created by operations to data used for decisionmaking. The SSRS API and report language are the fastest way to generate andexecute meaningful reports. The developer can spend their time thinking aboutwhat goes into a report. Pretty printing and data gathering are handled by theservice.

Figure 13: Theintroduction of SQL Server Reporting Services in 2004.

In our minds data is something we think about in etherealterms. Conceptually it exists far removed from the place it is stored. It ispure; never inconsistent or out-of-date. In the physical world of hardware,however, achieving the goal of ubiquitous data is not easy to solve. Startingin SQL Server 2005 several new services were created to isolate the applicationfrom having to worry about storage concerns. While we have not truly reach the stateof ubiquitous data yet, SQL Server has made and continues to make big stepsforward.

SQL Server 2005 saw the re-launch of DTS as SQLServer Integration Services (SSIS). The new paradigm of data warehousingrequired data to be extracted, transformed, and loaded (ETL) into everexpanding databases. While still retaining the capabilities of its predecessor,SSIS added new transformation capabilities and increased performance. Asbefore, SSIS is the application model for workflow applications close to thedatabase.

As shown in Figure 14, Microsoft SharePointentered the picture with SQL Server 2005. Since day one the data contained inSharePoint wiki sites was stored in SQL Server Databases, so SharePoint data isnaturally integrated. That is, since 2005 this data is directly accessiblethrough Reporting and Analysis Services. This integration makes the vast amountof data created every day by employees on wiki sites available to themanagement features. To the developer this means that SharePoint data becomesaccessible using the SQL programming model. A properly set up system can speedup programming SharePoint related applications.

SQL Server’s success also brought new issues.Applications became too popular for a single database to handle all thetraffic. SQL Server Broker elevated the programming model from authoring singleapplications to development of entire systems. The framework allows producersand consumers to collaborate in a low-latency, high-throughput system. Scale isachieved through load-balancing between multiple instances of a component inthe system.

Figure14: DTS was changed to SQL Server Integration Services in SQL Server 2005,which also included the addition of the Broker Service and natural integrationwith SharePoint databases.

Since 2005, the industry has witnessedtremendous expansion in the mobile device market. The number of devicesproducing and consuming data has been simply exploding.

It is very tempting for a mobile-phone appdeveloper to think of data as accessible and current regardless of the device’slocation and state. For this reason, the Microsoft Sync Framework introduced in2008 addressed the data needs underlying this scenario. It allows data to besynchronized across any number of devices using a number of differentsynchronization and conflict resolution algorithms.

SQL Server 2008 also added the SQL Server MasterData Service. The service builds on the idea that some data in the enterpriseis authoritative. This data is accessible through a single trusted source, theMaster Data Service, and is known to be correct at all times. The app can usethe same data access technologies to get at this data that are available forthe database.

In 2009 the database also moved to the cloudwith the introduction of SQL Azure. SQL Azure hosted the first customerdatabase in Microsoft-operated datacenters. The cloud database model removeshardware management from the list of concerns for the database operator.Developers can now truly think of the database as an unlimited source of dataresiding somewhere in the ether. Microsoft takes over most of the concernsassociated with operating a database server.

Thus the current view of support services in SQLServer is shown in Figure 15.

Figure15: SQL Server and SQL Azure with support services as of September 2010.