Interoperability is a big thing™. Applications, and indeed even platforms, have succeeded at least in part due to their ability to get things in and out easily. One of the main reasons WordPerfect became the standard in word processing was the fact that it could communicate with almost every printer in existence at the time. Similarly, Windows brought that same printer interoperability for all applications. As well, Windows brought another form of interoperability: database interoperability via ODBC (Open DataBase Connectivity). Before ODBC, the database was strongly tied to a front-end designer: if you wanted to keep your data in DBFs, you used DBase to get to them (or FoxPro, or Clipper, but let's not spoil an analogy with details). Switching databases usually meant switching front-end tools. Sure, PowerBuilder (and other tools) let us connect to other data sources, but invariably the language used to access these was different or proprietary to the front-end tool. With ODBC, you could access any data source (as long as there was an ODBC driver), and you could use a consistent (albeit least common denominator) language to query them. Other data access methods have come and gone (OLE DB, I'm looking sadly in your direction), but the main purpose remains the same: data wants to be free.
I'd like to think that SOAP (it used to be Simple Object Access Protocol, now "It's not an acronym") was going to be that ODBC for the Web, but alas, the standards committees got their fingers into it. Now we have WS-Security, WS-Routing, WS-JustBecause, WS-OnePersonLikedThis, and more. Implementing a solution between two companies drops you into a word soup of Document vs. RPC, SOAP 1.1 vs. 1.2, DIME vs. MTOM, and Basic vs. Enhanced Profiles (among many other choices). Obviously, there is a need for a simpler solution, and many developers have started to look to REST (REpresentational State Transfer) as a possible solution. Not a protocol, but more of a mindset: a way of designing applications to "work like the Web." With REST, your applications communicate with some back-end data store using basic URL-like messages that almost everyone understands. The back-end - in turn - replies with standard formats; again, formats that basically all platforms and developers can understand.
Open Data Protocol (or more simply, OData) is what Microsoft is calling their REST-like protocol. The client and server components of OData are based on WCF, but that is entirely an implementation detail. What is important is that with OData, you can access any data source (that understands its REST-like query language), and get back data that works with any platform. Alternately, you can use the client tools of OData to access any compatible data source.
The core of OData is Atom: by default, the data returned from an OData service is returned in Atom (with a few extensions that comply with the standard). This is one of my favourite features of OData: run the results of an OData service through a feed validator, and you will see the happy checkmark.
What about communicating with an OData service? Here you use URLs that uniquely identify the items stored in your data source. Need to retrieve all the product categories? That's at http://example.com/service.svc/ProductCategories. Just want the first one? http://example.com/service.svc/ProductCategories(1). Need to query based on some property of the data? http://example.com/service.svc/ProductCategories/?$expand=Products&$filter=CategoryName+eq+'Beverages'. Again, you get back a block of Atom (see above figure) that includes all the data, and links you can use to query for related data (like the products in the categories). Granted, these URLs are not part of the Atom standard, but they are easy enough to generate on any platform, by any programming language.
Editing the data in the store is almost as easy. If needed, you create an Atom (or JSON) entry of your own (to add a new element as an example), then use the appropriate HTTP verb.
||Used to create a new entry. The body of the message should include an Atom (or JSON) entry that will be added. The usual data validation is required here, so all required fields should exist and be of the correct scale/size.
||Used to update an entry. Typically, the URL will identify the item to be updated, and the new values will be contained in the body.
||Used to delete an entry (I bet you weren't expecting that!). Just as with PUT above, the item to be deleted will be identified by the URL.
While playing with URLs excites some of us, others prefer to use code to access our data. Here OData also makes things easy. You can use Visual Studio to create a client proxy class, just as you can with other SOAP or WCF services (see Figure). Once that's in place, you can then access the service:
nwConnection = new Northwind.NWEntities(new Uri(SERVICE_URL));
IQueryable products = from p in nwConnection.Products
Just in case you felt there was a little misdirection there, you can see in the debugger that the LINQ simply generates the appropriate URL (see Figure).
In turn, the client proxy converts the returned Atom into classes with all the desired properties that can be used just as with local classes (see Figure). The end result of all of this is that you have data accessible via the network (or Internet). While it can be accessed by any platform or language (even viewed in a browser), you can also use it locally just as though it were local data.
Also, it's not just Microsoft pushing OData: many other companies and governments have signed on to provide their data using OData. You can query SharePoint, Netflix, Stack Overflow, even the data from the cities of Edmonton and Vancouver! See the full list of producers on the OData site.
It's too early to tell if OData will become as ubiquitous or useful as ODBC, but it certainly has a great start towards making data easy to access from anywhere.
- Naming here is the usual Micromess. While OData is the standards effort Microsoft is proposing for their extensions to AtomPub, the technology itself is WCF Data Services, formerly known as ADO.NET Data Services. Despite them having little to do with ADO.NET (other than coming from the same team). Before that, it was known as Astoria, which to my knowledge has little to do with data access, but I hear it is a nice hotel.
- A few great tools for just experimenting with OData services include:
A great tool for any work with LINQ, it lets you point at an OData service and experiment with queries.
An invaluable tool for any work with HTTP.
A command-line tool for accessing URLs. Available for a number of operating systems.