Project Astoria, S+S, and Interop

With the unveiling of Project Astoria, we're seeing more and more "services in the sky" from Microsoft.  Of course there is the BizTalk Services ISB, which I commented on previously.  At Mix, Microsoft talked about a bunch of things, but one category was the Windows Live platform.

Lots of new services offerings, and lots more action to come in this area.  One of the philosophical underpinnings of the activity around Microsoft services, goes by the name of S+S inside the halls of Microsoft buildings.  S+S means "Software plus Services".  The traditional model for software has been to install software on-premise, on a machine (a server) located in a datacenter that you own and operate.  Services, on the other hand, promised to provide the capability of locally-installed software, without the locally-installed part.  This is often called SaaS, for Software-as-a-Service, but some people just call it Services. It's an overloaded term:  Ask EDS what they mean by "Services" and you'll get a different take!  For now I will call it "(software)services" to distinguish.

Anyway, the idea behind S+S is that people want the option to choose both locally-installed software, and remotely-accessible (software)services as their needs dictate.  Microsoft can't really be a broad supplier of software unless we do both, and offer customers choices.   That's what S+S attempts to express.

With all the activity around (software)services, keep in mind that these pieces can all be complementary to the existing software deployed in businesses today.  And also, these (software)services compose nicely into a SOA, which is an IT architectural approach Microsoft has been espousing for years now, specifically to enable this sort of opportunity - the opportunity to choose S+S. 

Getting back to Project Astoria, if you haven't looked - it is a data services platform for the web.  The idea is that apps can do HTTP GET's with special URLs to access data services.  Technologically, there is nothing really too revolutionary here, especially if you have previously looked at the SQLXML Query capability that is available with SQL2000 and SQL2005. I have online demos dating from 2004 showing interop - for example Java apps rendering XML derived from SQL, with ASPX pages consuming that (plain old) XML;  or conversely, ASPX pages rendering the XML and Java consuming the XML.   The big difference with astoria, of course, is that Astoria is a data service "in the sky" - it is on the internet, and is accessible to anyone. Another difference is that Astoria maps a generalized query and access model to a URI space. 

Now to the interop part - if you look at the examples of the Project Astoria data services, you will see that the data is returned in pretty clean-looking XML, or alternatively, JSON.  So this means these data services will be easily re-usable from any non-Microsoft platform, including Java, PHP, or anything that speaks HTTP GET.   and of course the new Web programmability stuff that will be delivered in the .NET Framework v3.5 later this year (codenamed "Orcas") will do very nicely, too, thankyou.

Nice!