Major trends are clearly drawn in the Web services landscape by now. Take for instance the use of the enterprise service bus (ESB) as an SOA enabler, or the widely debated SOAP vs. REST design approach, or how the WS-* stack addresses many enterprise scenarios. The point is that the industry's compasses are pretty much settled and pointing in the same direction. However, the way in which these trends are embodied by vendors into products is quite a different thing. So up next we will address one of the latest embodiments to come out of the Microsoft product-line, exploring its purpose as well as its relation to other Web services-related projects like Windows Communication Foundation (WCF) and .NET, its code-name: Project Astoria.
Astoria currently provides a very early roadmap on how REST type Web services will be designed and deployed in the Microsoft world, providing a series of tightly integrated hooks to those points typically associated with RESTful services -- a browser and serverside data layer -- while staying in a symbiotic relationship with other Microsoft developments in this space, namely Silverlight as a browser environment, Visual Studio as a development platform,and the .NET framework on the serverside.
The first distinction you should be aware of is that even though Astoria revolves around REST type Web services, it is actually two initiatives, one related to the programming model itself, which focuses on bringing structure to these type of designs, and another to publicly hosting such services on Microsoft infrastructure. Though it also should be mentioned the latter does not imply you can't host your own Astoria projects.
With that said, let's dig into the design benefits a project like Astoria brings to the table. All REST Web services are backed by some type of data layer, which is then exposed to support any of the classical HTTP methods -- GET, POST, PUT or DELETE -- a simple approach, but one that can be littered with heavy layers of scaffolding code, not to mention a very open-ended access structure for these types of services.
Astoria uses what is known as an Entity Data Model (EDM), a mechanism that simplifies the way in which a data object or relational database table is exposed as a REST service, and in the process enforces a more intuitive structure to access such data as a service. Take a look at the following listing which illustrates a piece of an Astoria based service.
Listing 1.1 - Astoria Web Data Service
using System;
using System.Web;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.Objects;
using Microsoft.Astoria;
using WeatherModel;
namespace ExampleDataService
{
public class Weather : WebDataService
{
}
}
What looks like a basic C# class, is actually a class already hooked onto an ADO.NET Entity which is tied to a database named Weather. Notice the class inheritance from WebDataService, which takes care of the scaffolding code needed to expose the Weather database and its corresponding objects as a REST service. This is an extremely stripped down sample, mainly because much of the code is extensive and created by Microsoft Visual Studio with a few points and clicks, so we won't delve into the actual model or database here.
Moving on, another benefit to using an EDM approach is that the URL access structure for such REST services is tied to the actual data model, giving way to a more streamlined convention of the form http://host/vdir/<service>/{<EntitySet>{<[predicate]>}{/<NavigationProperty>{<[Predicate]>}{/...}}}, something which is illustrated in the following listing:
Listing 1.2 - Astoria service access points, in-line with data model
http://localhost/Weather[City eq 'New York']?$format=json&$callback=cb
http://localhost/Weather?$orderby=Country desc,ZipCode
http://localhost/Weather?$skip=30&$top=10
Notice how these last URL's have a common pattern used to query REST services, something which enforces a standard mapping convention for accessing data models via a REST type interface. Similarly, if you were to try and access such a service without any parameters, you would get an XML response containing an empty list of entity-sets or a type of WADL descriptor like the following:
Listing 1.3 - Astoria descriptor with entity-sets.
<DataService xml:base="http://host/vdir/weather.svc">
<WeatherEntities uri=".">
<City href="City" />
<ZipCode href="ZipCode" />
<Country href="Country" />
<Date href="Date" />
</WeatherEntities>
</DataService>
So far this covers the majority of Astoria's offerings, but there is one more point to cover: the browser. Since a high percentage of REST services are used as the backbone for many Ajax applications, browser's also play an important role in the invocation process of REST services. Besides the now typical payloads of XML and JSON used in Ajax/REST interactions, Astoria brings a new addition to these interactions in the form of a client side API for Silverlight. Silverlight is of course the latest plug-in offered by Microsoft, which allows a browser to enhance the execution and display of rich data applications. So by offering such a client side API in Astoria, you can effectively make calls to Astoria services straight from within client-bound Silverlight applications.
Now that we've covered Astoria's fundamentals, you may be asking yourself were does this leave WCF, which is the wider encompassing Microsoft services platform. As it turns out, Astoria services are basically a special kind of WCF service designed around the REST paradigm. In fact, if you look at listing 1.3 you will notice that the service descriptor has a .svc extension just like any other WCF descriptor.
With this you can safely assume, Astoria essentially facilitates the creation of REST designs inside the Microsoft product line, while leaving the core and more enterprise focused features -- SOAP and WS-* -- to the broader WCF umbrella which forms part of the .NET framework. Though still in its early release cycle, Astoria proves to be a major building block in the near future given the growing popularity of RESTful Web services.
About the Author
Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics.
