Cloud Data: A Newbie Series --The issues.

  • Article

It's been an interesting couple of years for me -- I've been assigned to two different projects that have failed to find their way to RTM as originally conceived -- which cut my blog writing down a bit. It happens; I've been working most recently on some internal tools and demos designed to make use of the Microsoft cloud services and client technologies we have to make data accessible on any platform, always (or almost-always) available, reasonably efficient, and secure to the level that the value of the data requires.

Of course, that's the market-speak way of putting it; in point of fact, I wanted to build an application that makes use of private data, shares the appropriate amount publicly, and can be used from anywhere so that customers -- including me -- could use it the way that they wanted. This is a dumb, very normal idea -- get some data and build an app that actually uses it in a helpful way.

I'm actually trying to build two applications, but one is a tad behind schedule so I'll wait on that one. In any case, the first one required cutting the teeth a bit on a series of application technologies, assembled as loosely built cloud components using the following technologies:

  • Microsoft SQL Server 2008 and Express Edition with Advanced Services
  • Microsoft Linq2SQL -- a data access technology which is not our most supported technology, so far as I can see
  • Microsoft Entity Framework (EF)
  • SQL Azure
  • Windows Azure
  • https://www.linqpad.net/ -- a wonderful application for working with data in the cloud or locally
  • Visual Studio 2010
  • WPF
  • Windows Phone 7 with Silverlight
  • OData
  • WCF
  • WCF Data Services
  • Windows Azure DataMarket

I've touched each one of these items in order to create a working set of applications that can view, query, print, or send Microsoft technical and developer documentation topics based on internal metadata that is not used by search engines such as Google or Bing because they do not have access to it. The goal of this system, ultimately, is to enable any customer to find Microsoft information much faster than the global search engines can -- that is, you won't google or bing your question because you'll be able to locate the precise information you want based on query information the global services do not have.

Another way of saying this is that the applications aim to do one thing: unblock your work faster than any other current way within a specific problem domain. This isn't a global effort; I'm trying to keep the domain scope limited to data-centric .NET development with SQL Server 2008. But if your work touches this area, the idea is that the apps should be able to beat every other mechanism of finding your answer. If I can do that within a small domain, we can see where we can take that in larger problem spaces.

This is my gig; but along the way, I've touched so many different technologies that what I hope will end up being of help is the code that shows how to work with different technologies together -- you might not care for my specific effort. You have your own. :-)