Freigeben über

Data + Application Services + Sync= “It’s Still All Data” (the new again-expanded Data Developer Center)

  • Artikel

Last November, at the start of the 2009 PDC, we launched an expanded Data Developer Center that incorporated XML and SQL Server Modeling (formerly “Oslo”) technologies. It was a challenge to create a site structure that could accommodate eight or more distinct technologies under one roof, but it seemed to work well and allowed space for future expansion.

Today we’ve taken the next step in that expansion by bringing in the next ring of data-focused developer technologies. Some of these may seem a bit surprising, which is exactly why we’re pulling them in under Data. Our intent is to create a clear, developer-centric view of all Microsoft’s data-oriented technologies, meaning that you get all the goods that will help you create great applications without the marketing.

Here, then, is the roster of technologies that now appear on the Data home page (as well as the Learn page and elsewhere); * indicates those that have been added:

So the big question, of course, is why are we doing this? What’s the deal with bringing all these SQL Server specific technologies into the mix? Is this just an underhanded means to promote SQL Server? Didn’t you just say this wasn’t about marketing?

 

SQL Server: Database Engine vs. Application Services

That’s right—it’s not about marketing: it’s about clearly exposing developer surface areas where they’ve long been hidden. So while the SQL Server product as a whole does include a core database engine, SQL Server also includes a number of powerful developer-oriented features that just so happen to utilize SQL Server internally to do their jobs.

Let’s look at this generally. Say you want to build a service for doing reports that can be used by many different data-driven applications, where those applications may themselves be built on a variety of data platforms. To accomplish this, your service would need to collect and store information from those other applications. Where, then, do you store your particular information? You store it in a database, of course, so you would choose some reasonable database product to fulfill that particular role. In that sense, the underlying database technology used by your reports service is really just an implementation detail—what really matters is the developer surface area (API) that helps developers write better applications more easily.

Well, this is exactly what those SQL Server “services” are all about (including the future SQL Server Modeling Services). These are all “roles” for SQL Server in that they internally require a database to operate, and they just so happen to SQL Server for this purpose. This affinity is why they carry a SQL Server name.

However, they do not demand than applications that employ these powerful and mature APIs must also use SQL Server for their own primary storage needs. Not at all—as with other data access technologies from OBDC to ADO.NET to the Entity Framework, applications can and obviously must interoperate with a variety of database technologies. And they can continue to do so even if they employ APIs like SQL Server Integration Services for certain feature sets.

 

Helping Developers See the Services

We’ve found that many developers don’t realize that all these Application Services are developer APIs that can be used in this capacity. People hear “SQL Server” and they only think “database engine” and thus end up implementing their own reporting, analysis, integration, and synchronization services from scratch. Ouch!

By surfacing these technologies as partners with the well-known data access technologies, we’re thus hoping to increase awareness of these roles that SQL Server can play as powerful development tools above and beyond its being a database engine. And let us know, certainly, how well you think we’ve succeeded at this (or not).

Indeed, to underline this contrast, we’ve also chosen to separately distinguish the SQL Server database engines (including SQL Azure and SQL Compact), apart from the services. OK, so maybe this does plug those engines themselves a bit, but we felt it was necessary to set the proper context for the developer APIs we’re really trying to highlight. After all, you’re under no obligation to click those links!

 

Expanding Our Dev Center Organizational Model

Something else we’ve done with this mass-merging of additional technologies is to also expand on model of technology-specific landing pages that we started last November. The idea is that the Home and Learn pages are where you explore the whole gamut of technologies in order to make a more specific choice about the ones you’ll really be using. (For this purpose, by the way, we’ve updated the Data Development At-a-Glance and Data Development Technologies: Past, Present, and Future papers to include Application Services and everything else listed on the home page).

Once you make those choices, then, (and click on an appropriate link), you then arrive at an area that’s specifically focused on one technology. There we have prominent graphics for Get It (obtaining the technology), Beginner’s Guide (for on-ramping), and Learn More (for ongoing announcements, support, and deep-dive resources)—all of which is focused on the one technology. Thus within these landing pages, you’ll find specifically-relevant blog feeds, forum feeds, highlights, video and documentation links, book links, and so forth.

Thus we fully expect that you’ll often be branching off the main Data home page to those technologies of specific interest to you, as that’s where we’ll be highlighting technology-specific content. The main Data page, for its part, will continue to be where we highlight cross-technology content.

 

Would You Like to Contribute?

Speaking of content, we’d like to extend an invitation to you—the developer community—to participate in content creation for All Things Data. We really love your creative ideas because while we may be the ones creating these technologies, you’re the ones using them to create great value for the many customers we are all trying to serve.

So if you see opportunities to fill in gaps in the Data Developer Center content, please drop us both your suggestions as well as idea for articles, videos, etc., that you might like to produce. We can then work with you on that production (including technical and editorial review), and then find space on the Developer Center to share that content with the community and give you great exposure in return.

We look forward to hearing from you! You can reach us through dpfback (at) microsoft.com.

 

Kraig Brockschmidt
Community Program Manager for the Data Developer Center