Is OData The Ubiquitous Language For Application Collaboration?

Posted by Dilip Krishnan on Feb 02, 2010

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

SOA ,

REST ,

.NET

Tags

OData ,

AtomPub

The Open Data Protocol (OData) specification opens up possibilities to a lot of interesting collaborative scenarios. Some of which are highlighted by Douglas Purdy, Pablo Castro and Jon Udell. 

The Open Data Protocol (OData) is a web protocol for querying and updating data. OData applies web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores.

In an article, Jon Udell explores the various collaborative use-cases for the Open Data Protocol (OData) specification. He refers to an article in which Pablo Castro explains how aspects of the OData spec can be incrementally implemented...

OData is designed to be modular and grow as you need more features. We don't want to dictate exactly everything a service needs to do. Instead we want to make sure that if you choose to do something, you do it in a well-known way so everybody else can rely on that.

... as opposed to implementing the whole specification in one go. He suggests certain capability subsets that can be implemented such as Querying, Service metadata, batching etc.

We don't want to dictate exactly everything a service needs to do. Instead we want to make sure that if you choose to do something, you do it in a well-known way so everybody else can rely on that.

Douglas Purdy mentions one such implementation; and links to the folks at IBM who implemented the specification relying solely on the protocol documentation without ever having to collaborate with people at Microsoft! Also linked in a different post is a screen cast by Pablo that demonstrates the advantages of having a ubiquitous protocol serve as the glue that a wide variety of products in the Microsoft catalog have or will implement; that makes the exchange of data between them much simpler.

Jon Udel also beautifully demonstrates the power of such a protocol. In particular, the example he uses is one in which he filters of a list of bank locations in a certain area code and demonstrates how the OData feed can be consumed in Excel 2010’s PowerPivot to provide data analysis.

[If we] consider Pablo’s example, based on some Washington, DC datasets published using the Open Government Data Initiative toolkit. […] I’d like to suggest that there’s a huge benefit for users as well. Let’s look at one of those datasets, BankLocations, through the lens of Excel 2010’s PowerPivot”.

Jon concludes his article with a very interesting observation on the decentralized, collaborative network effects such services can produce.

When public datasets provide fully articulated web namespaces, though, things can happen in a more loosely coupled way. I can post my feedback anywhere — for example, right here on this blog. If I have something to say about the WashingtonFirst branch at 1500 K Street, NW, I can refer to it using an URL: 1500 K Street, NW. […] That URL is, in effect, a trackback that points to one record in the dataset. The service that hosts the dataset could scan the web for these inbound links and, if desired, reflect them back to its users.

To further such loosely coupled collaboration, Microsoft introduced a service Codename "Dallas", an information marketplace that brings data, imagery, and real-time web services from leading commercial data providers and authoritative public data sources together into a single location.

• Older >