The top story in my favorite aggregator today is the announcement on Scott Guthrie’s blog of the ASP.NET 3.5 Extensions CTP Preview. Normally, announcements related to ASP.NET would not interest me except this time is an interesting item in the list of technologies being released

ADO.NET Data Services: In parallel with the ASP.NET Extensions release we will also be releasing the ADO.NET Entity Framework.  This provides a modeling framework that enables developers to define a conceptual model of a database schema that closely aligns to a real world view of the information.  We will also be shipping a new set of data services (codename "Astoria") that make it easy to expose REST based API endpoints from within your ASP.NET applications.

Wow. It looks like Astoria has quickly moved from being an experimental project to see what it would like to place RESTful interfaces on top of SQL Server database to being very close to shipping a production version.  I dug around for more posts about Astoria ADO.NET Data Services so I could find out what was in the CTP and came across two posts from Mike Flasko and Andy Conrad respectively.

In his post entitled ADO.NET Data Services ("Project Astoria") CTP is Released on the ADO.NET Data Services team blog Mike Flasko writes

The following features are in this CTP:

  • Support to create ADO.NET Data Services backed by:
    • A relational database by leveraging the Entity Framework
    • Any data source (file, web service, custom store, application logic layer, etc)
  • Serialization Formats:
    • Industry standard AtomPub serialization
    • JSON serialization
  • Simple HTTP interface
    • Any platform with an HTTP stack can easily consume a data service
    • Designed to leverage HTTP semantics and infrastructure already deployed at large
  • Client libraries:
    • .NET Framework
    • ASP.NET AJAX
    • Silverlight (coming soon)

This is sick. With Astoria I can expose my relational database or even a local just an XML file using a RESTful interface that utilizes the Atom Publishing Protocol or JSON. I am somewhat amused that one of the options is placing a RESTful interface over a SOAP Web Service. My, how times have changed…

It is pretty cool that Microsoft is the first major database vendor to bring the dream of the Atom store to fruition. I also like that one of the side effects of this is that there is now an AtomPub client library for .NET Framework. Smile

Andy Conrad has a blog post entitled Linq to REST which gives an idea of what happens when you combine the Astoria client library with the Language Integrated Query (LINQ) features of C# 3.0

    [OpenObject("PropBag")]
    public class Product{
        private Dictionary<string, object> propBag = new Dictionary<string, object>();

        [Key]
        public int ProductID { get; set; }        
        public string ProductName { get; set; }        
        public int UnitsInStock { get; set; }
        public IDictionary<string, object> PropBag { get { return propBag; } }
    }

        static void Main(string[] args){
            WebDataContext context = new WebDataContext("http://localhost:18752/Northwind.svc");
            var query = from p in context.CreateQuery<Product>("Products")
                        where p.UnitsInStock > 100
                        select p;

            foreach (Product p in query){
                Console.WriteLine(p.ProductName + " , UnitsInStock= " + p.UnitsInStock);
            }

        } 

If you hover over the query variable, you will actually see the Astoria URI which the Linq query is translated into by the Astoria client library:

http://localhost:18752/Northwind.svc/Products?$filter=(UnitsInStock)%20gt%20(100)

So, there you go.  Linq to Astoria's RESTFUL API.  In other words, Linq to REST. 

Like I said earlier, this is sick. I need to holla at Andy and see if there is a dependency on the Atom feed containing Microsoft specific extensions or whether this Linq to REST capability can be utilized over any arbitrary Atom feed.

Now playing: Jay-Z - Success (feat. Nas)


 

Tuesday, 11 December 2007 15:40:27 (GMT Standard Time, UTC+00:00)
Dare,

I assume you left an "l" out of "This is sick!"

Cheers,

--rj

http://oakleafblog.blogspot.com/2007/12/aspnet-35-extensions-preview-released.html
Tuesday, 11 December 2007 21:29:13 (GMT Standard Time, UTC+00:00)
What does "Industry standard AtomPub serialization" mean?

I'd be happy to check it out with the Ape code if someone could expose a server instance.
Tuesday, 11 December 2007 22:43:11 (GMT Standard Time, UTC+00:00)
Wonder if you could help me out here because I'm not really seeing what the benefits to ATOM are.

Say I want to expose an account resource via ATOM,
isn't my xml going to be stuffed into an ATOM item somewhere?

What's the difference between an ATOM envelope or a SOAP envelope? Aren't we going to be reinventing the wheel?
Wednesday, 12 December 2007 00:35:49 (GMT Standard Time, UTC+00:00)
Tim: by "industry standard" we mean that we took the atom/atompub RFCs and followed them while implementing our serializers/deserializers for atom. We haven't ran any compliance check tools yet, so I wouldn't be surprised if a number of issues come up.

btw - If you have an opportunity to look at the mapping to ATOM that we chose on Astoria I'd love to hear your thoughts about.

-pablo
Wednesday, 12 December 2007 17:57:31 (GMT Standard Time, UTC+00:00)
Does Astoria work on top of WCF or is it a separate project to expose REST services?
Ranji
Wednesday, 12 December 2007 18:01:15 (GMT Standard Time, UTC+00:00)
> If you have an opportunity to look at the mapping to ATOM that we chose on Astoria I'd love to hear your thoughts about.

Where can I find this mapping? I'd be willing to review it.
Thursday, 13 December 2007 07:16:44 (GMT Standard Time, UTC+00:00)
Of course, C# 3.0 isn't the only language with LINQ support. VB 9.0 does LINQ, and has some unique features for both XML and relational query.

Sam

(which Dare knows, of course, but it's worth a reminder ;)
Thursday, 13 December 2007 08:13:38 (GMT Standard Time, UTC+00:00)
Pablo: I'm asking because by "atompub" people usually mean the Atom Publishing Protocol (RFC5023, or APP), which is not a serialization format. So the initial statement is a little hard to parse.

If what you're doing is serializing your resources using the Atom format (RFC4287), that's a good thing (and the place to go for sanity-checking is feedvalidator.org).

If what you're doing is allowing client CRUD operations via APP, that's also super-cool; please come to one of the APP interop events and you'll learn a whole lot real quick about any rough edges, and help expose other people's. And if you'd like to have a run with the Ape, gimme a shout.

If you're doing both of these things, that's extra good. Help me with the parsing.
Saturday, 15 December 2007 21:07:04 (GMT Standard Time, UTC+00:00)
Tim: yes, you're right it's confusing, we need to clean up our terminology. To be totally transparent, we have this struggle where in some cases we support just a format and use our own protocol (JSON), and in other cases we actually follow a protocol (APP). "Our own" protocol in practice is not really a custom protocol but just HTTP, which makes it very close to APP (we are still having some debates about replace versus merge behavior and stuff like that).

For the case of ATOM, we actually follow APP, and thus ATOM for the format. Clients can do CRUD operations using regular APP semantics, retrieve service documents, follow links, etc. We do have some added semantics on top, naturally, but we're trying hard to make sure that they don't get in the way of clients that don't know about them.

As we have more serious content to present we'll keep the ATOM community updated (I guess sending notes to atom-syntax@imc.org). Good suggestion around APP interop events. If you have specific suggestions on where we should show up I'd love to hear it.

-pablo
Comments are closed.