Introducing OData

Our world is awash in data. Vast amountsexist today, and more is created every year. Yet data has value only if it canbe used, and it can be used only if it can be accessed by applications
and thepeople who use them.

Allowing this kind of broad access todata is the goal of the Open Data Protocol, commonly called just OData. Thispaper provides an introduction to OData, describing what it is and
how it canbe applied. The goal is to illustrate why OData is important and how yourorganization might use it.

The Problem: Accessing Diverse Data in aCommon Way

There are many possible sources of data.Applications collect and maintain information in databases, organizations storedata in the cloud, and many firms make a business out of selling
data. And justas there are many data sources, there are many possible clients: Web browsers,apps on mobile devices, business intelligence (BI) tools, and more. How canthis varied set of clients access these diverse data sources?

One solution is for every data source todefine its own approach to exposing data. While this would work, it leads tosome ugly problems. First, it requires every client to contain
unique code foreach data source it will access, a burden for the people who write thoseclients. Just as important, it requires the creators of each data source tospecify and implement their own approach to getting at their data, making eachone reinvent this
wheel. And with custom solutions on both sides, there's noway to create an effective set of tools to make life easier for the people whobuild clients and data sources.

Thinking about some typical problemsillustrates why this approach isn't the best solution. Suppose a Webapplication wishes to expose its data to apps on mobile phones, for instance.Without
some common way to do this, the Web application must implement its ownidiosyncratic approach, forcing every client app developer that needs its datato support this. Or think about the need to connect various BI tools withdifferent data sources to answer business
questions. If every data sourceexposes data in a different way, analyzing that data with various tools is hard-- an analyst can only hope that her favorite tool supports the data accessmechanism she needs to get at a particular data source.

Defining a common approach makes muchmore sense. All that's needed is agreement on a way to model data and aprotocol for accessing that data -- the implementations can differ. And
giventhe Web-oriented world we live in, it would make sense to build this technologywith existing Web standards as much as possible. This is exactly the approachtaken by OData.

The Solution: What OData Provides

OData defines an abstract data model anda protocol that let any client access information exposed by any data source.Figure 1 shows some of the most important examples of clients
and data sources,illustrating where OData fits in the picture.

As the figure illustrates, OData allowsmixing and matching clients and data sources. Some of the most importantexamples of data sources that support OData today are:

· Custom applications: Rather thancreating its own mechanism to expose data, an application can instead useOData. Facebook, Netflix, and eBay all expose some of their information
viaOData today, as do a number of custom enterprise applications. To make thiseasier to do, OData libraries are available that let .NET Framework and Javaapplications act as data sources.

· Content management software: Forexample, SharePoint 2010 and Webnodes both have built-in support for exposinginformation through OData.

· Windows Azure MarketplaceDataMarket: This cloud-based service for discovering, purchasing, and accessingcommercially available datasets lets applications access those datasets
throughOData.

While it's possible to access an ODatadata source from an ordinary browser -- the protocol is based on HTTP -- clientapplications usually rely on a client library. As Figure 1 shows,
the optionssupported today include:

· Web browsers: JavaScript coderunning inside any popular Web browser, such as Internet Explorer or Firefox,can access an OData data source. An OData client library is available
for Silverlightapplications as well, and other rich Internet applications can also act asOData clients.

· Mobile phones. OData clientlibraries are available today for Android, iOS (the operating system used byiPhones and iPads), and Windows Phone 7.

· Business intelligence tools:Microsoft Excel provides a data analysis tool called PowerPivot that hasbuilt-in support for OData. Other desktop BI tools also support OData
today,such as Tableau Software's Tableau Desktop.

· Custom applications: Businesslogic running on servers can act as an OData client. Support is available todayfor code created using the .NET Framework, Java, PHP, and other
technologies.

The fundamental idea is that any ODataclient can access any OData data source. Rather than creating unique ways toexpose and access data, data sources and their clients can instead
rely on thesingle solution that OData provides.

OData was originally created byMicrosoft. Yet while several of the examples in Figure 1 use Microsofttechnologies, OData isn't a Microsoft-only technology. In fact, Microsoft hasincluded
OData under its Open Specification Promise, guaranteeing theprotocol's long-term availability for others. While much of today's ODatasupport is provided by Microsoft, it's more accurate to view OData as a generalpurpose data access technology that can be used
with many languages and manyplatforms.

How OData Works: Technology Basics

Providing a way for all kinds of clientsto access all kinds of data is clearly a good thing. But what's needed to makethe idea work? Figure 2 shows the fundamental components of
the ODatatechnology family.

Figure 2: An OData service exposes data via the ODatadata model, which clients access with an OData client library and the ODataprotocol.

· The OData protocol, which lets a client make requests toand get responses from an OData service. At bottom, the OData protocol is a setof RESTful interactions
-- it's just HTTP. Those interactions include the usualcreate/read/update/delete (CRUD) operations, along with an OData-defined querylanguage. Data sent by an OData service can be represented on the wire todayeither in the XML-based format defined by Atom/AtomPub
or in JavaScript ObjectNotation (JSON).

· OData client libraries, whichmake it easier to create software that accesses data via the OData protocol.Because OData relies
on REST, using an OData-specific client library isn'tstrictly required. But most OData clients are applications, and so providingpre-built libraries for making OData requests and getting results makes lifesimpler for the developers who create those applications.

· An OData service, which exposes an endpoint that allowsaccess to data. This service implements the OData protocol, and it also usesthe abstractions of the
OData data model to translate data between itsunderlying form, which might be relational tables, SharePoint lists, orsomething else, into the format sent to the client.

Given this basic grasp of the ODatatechnology, it's possible to get a better sense of how it can be used. The bestway to do this is to look at some representative OData scenarios.

Using OData: Example Scenarios

Because OData is a general-purpose dataaccess mechanism, it can be used in many different ways. This section looks atthree representative examples:

Users commonly access Web applicationstoday through browsers. More and more, however, custom client applications areused in place of browsers, especially on mobile devices. And
when those clientapps need to access a Web application's functionality, using standard RESTcalls can work well.

But exposing data is harder. Withoutconventions for doing this, the creator of a Web application needs to create adata model (since he probably doesn't want to expose his application's
internaldatabase structure to the world), a query language (to allow more than justsimple reads), client libraries (to help diverse clients access the data), andperhaps even tools (to help people create those clients).

If the application instead exposes itsdata through OData, life gets significantly simpler -- these things are alreadyavailable. Figure 3 illustrates this, showing how a custom application
can useOData to expose its data both to client apps on mobile phones and to Webbrowsers.

In this example, data exposed by a Webapplication is accessed by client apps running on three different kinds ofmobile devices: Android, iPhone/iPad, and Windows Phone 7. All three
rely onOData client libraries made available by Microsoft today, and all three see thesame data model exposed by the custom application's OData service. Whenrequesting data via the OData protocol, each application can choose the formatit wants that data delivered
in: XML with Atom/AtomPub or JSON.

Similarly, JavaScript code running in aWeb browser uses another Microsoft-provided OData client library to access theapplication's data. The data is exposed using the same data
model, and it'saccessed via the same OData protocol. Because the client is written inJavaScript, it probably elects to have data delivered to it in JSON (althoughthis isn't required). And although it's not shown in the figure, Microsoft alsoprovides an OData
client library for Silverlight, supporting more functionalbrowser applications.

It's important to understand thatnothing about OData requires an application to expose the structure of itsinternal data to clients. A client only sees the data model provided by
theOData service, not the raw underlying data. How the application maps its datato the OData data model is entirely up to the developer. If the underlying datasource is relational tables, for example, she might choose to reflect one ormore tables directly
in her application's OData data model, but perhaps omit someof columns in these tables. Alternatively, she might create an entirelydifferent mapping where the OData data model is quite different from theunderlying database.

Whatever choice she makes, the ODataservice is free to interpose logic, such as rules for access control, betweenclients and that data. Using OData needn't mean that clients can
see directlyinto the structure of an application's data.

It's also important to understand thatOData is designed to protect data sources from clients that request too muchdata. As long as clients request small amounts of data, this problem
doesn'tarise. But suppose a client requests all of the data in, say, a relationaltable -- what then? Is the OData service obligated to return everything in asingle response? The answer is no. Instead, a service is free to define its ownpage size, then return
data a page at a time. It can also provide acontinuation indicator, letting the client request the next page. Because ofthis, a client request for a large amount of data needn't overwhelm an ODataservice's ability to deal with it.

Exposing Data from a Cloud Application

Cloud platforms are changing how webuild and run applications. They're also changing how we store and access data.OData can play a role in these changes.

For example, think about a firm thatsells products directly to customers via the Web. Suppose this firm also wishesto let partner organizations access its product information from
their ownapplications. To do this, the firm might build an application and store itsdata on a cloud platform, such as the Windows Azure. This cloud applicationwill interact with users via browsers as usual. It can also use OData to exposethe application's
data to software created by its partners. Figure 4 shows howthis looks.

Figure 4: Diverse applications can use OData to accessdata stored in the cloud.

As the figure shows, the Windows Azureapplication interacts with customers via browsers. This application might bebuilt using the .NET Framework or Java or something else -- Windows
Azuresupports several options. Whatever language it's in, the application can exposean OData service to provide external access to its data. In this example,partners have created applications using PHP and Java, both of which have ODataclient libraries available.
These partner applications then interact with theirown users through browsers or perhaps in some other way, accessing the clouddata as needed. This approach, with an application providing a standard browserinterface while also exposing its data to other applications,
is a common wayto use OData today.

A partner application can also use ODatato access information that the cloud application stores in Windows Azuretables, as Figure 4 illustrates. OData is the native access protocol
forWindows Azure tables, and as long as it's authorized to do so, another applicationcan work directly with this information. It's more common today to expose anOData service from an application rather than directly from a data store, butboth approaches are
possible.

Using Diverse Data Sources with DifferentBI Tools

Business intelligence, analyzinginformation to extract meaning, is an important part of how people use data.Analyzing data first requires accessing data, and given the multiplicity
of BItools and data sources in use today, this is a non-trivial problem. Differentanalysts prefer different tools, and data is kept in different forms indifferent places. Much of an organization's useful data is likely to be wrappedinside custom and packaged
applications, for example, while many organizationsalso keep useful business data in SharePoint lists. Another possible source fordata is Microsoft's Windows Azure Marketplace DataMarket, which provides acloud-based way to purchase and access commercial data
sets.

Suppose an analyst wishes to combinedata from these various sources. Maybe a retailer is trying to decide where tolocate a new store, for example, and so needs to look at sales
information fromone of its custom applications, customer survey data stored in SharePointlists, and demographic data acquired from DataMarket. Or perhaps analysts in alocal government wish to access emergency call data from the city's custom callcenter application,
police reports stored in SharePoint, and national crimestatistics available through DataMarket. In both cases, it's entirely possiblethat different analysts wish to use different tools to work with this data.

The problem is clear: How can we connectmultiple clients to multiple data sources? Without a common approach toexposing and accessing data, the situation is bleak. OData can help,
as Figure5 shows.

Figure 5: Different BI tools can use OData to access datastored in different formats across different data sources.

In this example, two different analystsusing different BI tools -- Tableau Desktop and Microsoft Excel's PowerPivot --are accessing data from the three data sources just listed
: SharePoint 2010lists, a custom application, and Windows Azure Marketplace DataMarket. All ofthese technologies can use OData today, and so making these connections isstraightforward. Because clients and data sources speak the common language ofOData, hooking
them together gets simpler, and analysts can begin working withnew data more rapidly.

Examining OData: A Closer Look at theTechnology and Its Implementation

OData began life as a Microsoft projectcode-named Astoria. The technology was then renamed ADO.NETData
Services before its protocol and data model were separated out and becameOData. (The parts of ADO.NET Data Services that were focused on the Windowsimplementation of OData are now known as WCF
DataServices.) Whatever thename, though, the fundamental technology of OData has remained the same.

As described earlier, it's useful tothink about the OData world in four parts: the data model, the protocol, theclient libraries, and the OData service itself. This section describes
allfour, beginning with the data model.

The OData Data Model

To provide a general way for any clientto access any kind of information, OData provides an abstract data model. Yetdata comes in many different forms, and it can be related to
other data in avariety of ways. How can a single data model encompass this diversity?

OData's answer is the Entity Data Model.In many ways a modern take on the familiar entity-relationship model, the EDMmodels data as entities and associations among those entities.
This generalapproach lets the EDM -- and

thus OData -- work with pretty much anykind of data. Figure 6 illustrates the fundamentals of how the EDM describesdata.

As the figure shows, associationsbetween entities can be one-to-one or many-to-one. An association can also beunidirectional, as are most of those shown here, or bi-directional,
like theassociation in the upper right. Whatever structure is used, it's important tounderstand that the EDM describes only the logical structure of data. How thatdata is stored physically is irrelevant.

The data exposed by an OData service cancome from many sources, and how this data is mapped to the EDM is up to thecreator of that service. For example, an OData service exposing
relational datamight represent each table as an entity, with foreign key relationships amongthose tables modeled as associations. A service that's exposing data directlyfrom a set of Java objects might model each object as an entity and theconnections among
objects as associations.

There's more to the EDM than justentities and associations, however. Figure 7 shows a more complete picture.

Figure 7: In the EDM, an entity container holds entitysets, while each entity has one or more properties.

As the figure shows, the EDM organizesentities into a simple hierarchy. Each entity is part of an entity set,
and each entity set belongs to an entitycontainer. Entities, eachof which is of some entity type, also have a simple structure: They contain properties,
each of which contains data that thisentity holds. To describe the data in properties, the EDM defines a variety ofdata types, such as String, Boolean, Int16, Int32, Binary, and DateTime.

Special properties called navigation properties represent associations-- they implement connections
between entities. In the example show here, forexample, each entity set might be a table in a relational database, with eachentity a row in that table. Navigation properties represent relationshipsbetween rows, such as those expressed by foreign keys.

Having a general model for all kinds ofdata is essential. Without it, OData couldn't give clients a common view ofdiverse data sources. Useful as it is, though, the EDM isn't enough.
There mustalso be a way for an OData client to send requests to an OData service, thenget data back. The OData protocol defines how to do this, as described next.

The OData Protocol

The OData protocol is based on REST; atbottom, it's just HTTP. But HTTP alone isn't enough. OData also defines howdata modeled using the EDM should look on the wire, how to form
queries againstthat data, and more. This section takes a closer look at these aspects of thetechnology.

Protocol Basics

An OData client accesses data providedby an OData service using standard HTTP. The OData protocol largely follows theconventions defined by REST, which define how HTTP verbs are
used. The mostimportant of these verbs are:

· GET: Reads data from one or moreentities.

· PUT: Updates an existing entity,replacing all of its properties.

· MERGE: Updates an existingentity, but replaces only specified properties[2].

· POST: Creates a new entity.

· DELETE: Removes an entity.

As usual with REST, each HTTP request issent to a specific URI, identifying some point in the target OData service'sdata model. For example, the root URI for a service might bewww.fabrikam.com/example.

A client can typically learn about thedata model used by an OData service by issuing a GET on a service's root URIwith "$metadata" appended to it. For example, issuing the HTTPrequest

GET http://www.fabrikam.com/example/$metadata

returns a description of the EDM schemafor the data model exposed by this OData service. The returned schema isexpressed in an XML-based format called the conceptual schema definitionlanguage
(CSDL), and an OData client can examine it to see what the service'sdata model looks like.

Like most data access protocols, ODatamust handle authentication: How does a client prove its identity to an ODataservice? The answer is that since OData is based on REST, any authenticationscheme
that works in a RESTful context will work here. For straightforwardinteractions, communication between OData clients and services can rely on HTTPBasic Authentication over SSL. For more complex scenarios, Microsoft recommendsusing OAuth 2.

Serializing Data with Atom/AtomPub

The purpose of the OData protocol is tolet a client get data from an OData service. While the EDM defines an abstractdata model, it says nothing about how that data should be serialized,
i.e., howit should be represented on the wire. To fill this gap, OData today defines twoserialization options: one using the XML-based Atom/AtomPub and another usingJSON. Both are worth looking at, beginning with the more commonly usedAtom/AtomPub.

Atom, defined in RFC 4287, wasoriginally created to describe information in blogs. It models a blog as a feed that
provides data to its readers.Each feed contains some number of entries, each of which holds the content of aparticular blog entry. AtomPub, officially known as the Atom PublishingProtocol,
defines the notion of a service that contains one or more collections. It also defines a set of RESTfulinteractions
for accessing a service.

Figure 8: Atom and AtomPub together define an XMLrepresentation of data organized into a hierarchy.

In the Atom/AtomPub world, eachcollection is mapped to a feed. For a client to learn what blogs a particularsite makes available, it can ask the AtomPub service for the collections
itcontains, then access the feed that each collection represents. The Atom andAtomPub specifications define how to represent this in XML, providing aconcrete way to send information across the network.

All of this raises an obvious question:What does a data model originally created for blogs have to do with the kind ofgeneral purpose data access that OData allows? The answer is
that from itshumble blog origins, Atom/AtomPub has grown into a widely used approach forworking with a variety of data on the Web. (In fact, the creators of AtomPubexplicitly intended to design something that would be more broadly useful.)Given this popularity,
OData's creators chose to adopt it for an XMLserialization format rather than create something new.

Like the EDM, Atom/AtomPub organizesinformation into a hierarchy: A service contains collections, each of whichcorresponds to a feed, with each feed containing entries. Mapping
the EDM toAtom/AtomPub is straightforward, as Figure 9 shows.

Figure 9: OData can use Atom/AtomPub to serializeEDM-defined data for transmission across the wire.

As the figure shows, an AtomPub servicecorresponds to an entity container in EDM. An AtomPub collection, together withthe Atom feed it's associated with, is mapped to an EDM entity
set. An Atomentry corresponds to an EDM entity, while both hierarchies represent actualdata values as properties. (Atom doesn't define properties, however -- this isan extension added by OData.)

To get a concrete sense of how theseabstractions are used, think about how an OData service might map data in arelational database first into the EDM, then into Atom/AtomPub for
transmissionto a client. Figure 10 summarizes the relationships.

Figure 10: Relational data can be mapped first to theEDM, then to Atom/AtomPub for transmission to an OData client.

Like the EDM and Atom/AtomPub, arelational database organizes data into a hierarchy. At the top is the databaseitself, which contains tables. Each table holds some number of rows,
while eachrow contains a set of column values. Mapping this to the EDM and Atom/AtomPub,the database itself corresponds to an EDM entity container, then to an AtomPubservice. Each table becomes an EDM entity set, represented as an AtomPubcollection and an
Atom feed. Each row in the table is an EDM entity and an Atomentry, while each column value becomes a property in both EDM and Atom.

To understand how this actually looks onthe wire, it's useful to walk through an example. Figure 11 shows a simplerelational database with two tables: Customers and Orders. Both
tables havethree columns, and both are exposed by an OData service with the URIwww.fabrikam.com/example. To begin accessing the data this service provides, anOData client can issue an HTTP GET on this URI, as Figure 11 shows.

Figure 11: Issuing a GET on the base URI of an ODataservice returns an AtomPub service document describing the collections (i.e.,the feeds) in that service.

The result of this GET is an AtomPub servicedocument. As its namesuggests, a service document contains
a list of what's available in thisservice, that is, what collections the service contains. Here's a sketch ofwhat that service document looks like for the example in Figure 11:

As described earlier, each of thedatabase's tables is represented as an AtomPub collection. The client can thenaccess a particular table with another GET request. For example, to
access theOrders table, the client issues a GET on the URIwww.fabrikam.com/example/Orders. Doing this returns an Atom feeddocument, as shown inFigure 12.

Figure 12: Issuing a GET on a feed's URI returns a feeddocument containing that feed's data, such as the contents of a table.

Because an EDM entity set (and thus atable) is mapped to a feed, each feed document references a single table. Doinga GET on a feed returns the entire contents of the Orders table
in a feeddocument with each row as an entry. Here's a simplified version of how thatdocument looks:

The feed document begins by referencingXML namespaces containing types that OData needs. It then specifies the titleof the feed (i.e., the table) being returned, followed by an
XML element foreach entry (i.e., each row) in that table. In this simple example, the tablehas only three columns, so each entry has three properties. Notice thatproperties and their data types are borrowed from the EDM -- Atom has no notionof either one.
And since the default type is string, there's no need toexplicitly specify a type for the characters in the Statusproperty.

It's also possible to request just partsof a table. For example, issuing a GET on the URIwww.fabrikam.com/example/Orders(5630)returns an Atom feed document containingonly the entry
whose primary key is 5630. Assuming that the OrderID column isthe key for this table, that document would contain just the second of the twoentries shown above. Another option is to use the $count option to request justthe number of entries in a feed. For
example, issuing the request

http://GET www.fabrikam.com/example/Orders/$count

returns the number of entries (that is,the number of rows) in the Orders table.

Atom/AtomPub can be used to serializeany set of EDM-defined data -- it's not just for relational tables. Forexample, a group of SharePoint lists can be viewed as an AtomPub service,
witheach individual list an Atom feed. Each of a list's items then becomes anentry, with each field in that entry represented as a property. Other datasources can be mapped in a similar way.

Serializing Data with JSON

JavaScript Object Notation is a way torepresent information on the wire and in other contexts. Described in RFC 4627,JSON is derived from the syntax of JavaScript, which makes life
simple forJavaScript developers. Unsurprisingly, JSON has become a popular choice fordata sent to applications running in Web browsers. JSON support is availablefor multiple languages, however -- it's not only for JavaScript -- and becauseit provides a simple
and compact way to represent data, it's a useful optionfor serializing information.

Whether an OData client chooses to havethe data it receives serialized using Atom/AtomPub or JSON, the way itinteracts with an OData service is the same. In both cases, the client
cantypically ask an OData service for a document that describes all of theavailable entity sets (collections/feeds in the parlance of Atom/AtomPub), thenrequest the data those entity sets contain.

For example, a client using JSON couldask the example OData service shown earlier for a list of all of its entitysets with the same request used to get an AtomPub service document:

http://GET www.fabrikam.com/example

With JSON, however, the resultingdocument looks like this:

{ "d" : { "EntitySets": ["Customers", "Orders"]
} }

The "d" stands for"data", and it's used to wrap all JSON results returned from an ODataservice. Here those results are the two entity sets Customers and Orders,representing the
two relational tables exposed by this service.

A client can then request entities inthose entity sets, which in this example means rows in tables. For instance,suppose a client asks for the row in the Orders table with the key
5630 byissuing the request

It's worth re-emphasizing that theapproach OData uses to model data -- the EDM -- is entirely separate from itsserialization formats of JSON and Atom/AtomPub. (Even though it's
common totalk about "OData feeds", for instance, Atom feeds aren't a requiredpart of the technology.) The separation between the EDM and serialization alsomeans that the OData URIs and protocol semantics are the same regardless of theserialization format used.
This separation makes it straightforward to addother serialization formats in the future; the technology isn't wedded towhat's popular today.

Issuing Queries

Invoking a GET on a URI is useful, butit's a blunt instrument. Clients also need a way to issue more precise querieson data, something that Atom/AtomPub doesn't define. To meet
this need, ODatadefines a query language.

The OData data model isn't relational,and so this query language isn't SQL. Instead, it defines a set of options thatcan be appended to a GET request. The possibilities include:

· $top=n: Returns only the first nentities in an entity set (or in Atom terms, the first n entries in a feed).

· $skip=n: Skips the first nentities in an entity set. Using this option lets a client retrieve a series ofdistinct pages on subsequent requests.

· $format: Determines whether datashould be returned in JSON or the XML-based Atom/AtomPub format. (The defaultis Atom/AtomPub.)

· $orderby=: Orders results, inascending or descending order, by the value of one or more properties in thoseresults.

· $filter=: Returns only entitiesthat match the specified expression.

· $select=: Returns only thespecified properties in an entity.

The last three options all rely on ODataexpressions. These expressions can contain many different operators, all ofwhich are represented as text. For example, equality is indicated
by the string"eq", greater than by "gt", and addition by "add"[3]. To return, say,entities for all orders whose OrderID is between 3,000
and 5,000, an ODataclient could issue this HTTP request:

Along with operators, the OData querylanguage provides string operations, date/time operations, and more.

An OData service can also define serviceoperations, pre-defined functions that clients can invoke. For example, aservice that stores pictures might expose a service operation that
lets clientsapply various effects to an image. Service operations can also be used toexpose stored procedures from a database or in other ways.

As described earlier, one clearadvantage of OData is its commonality: Rather than having each applicationdefine its own unique set of services, they can all use the common data
modeland protocol defined by OData. This makes it easier to mix and match clientsand data sources, and it also allows using common libraries to create both.

But there's also another reason whyOData can be better for exposing data than a traditional SOA approach. Supposean application needs to expose data about customers and orders to
variousclients. With the SOA approach, the application's creators would define a setof custom operations (using either REST or SOAP) that clients could call. Theymight, for example, create a GetCustomer operation that returned data about oneor more customers.
If the application's first client wanted the ability toretrieve customers by customer number, this operation might have a parameterthat allowed making exactly this kind of request.

Now suppose another client wants toaccess this application's data through the same interface. This client needs toretrieve customer data by geographic area, however, rather than
by customernumber. To allow this, the creator of the application's interface likely adds anew operation, perhaps called GetCustomerByGeo. When yet another clientappears, it might well want to retrieve customer data in some other way,requiring still more changes
to the interface.

It's common to see this kind ofevolution in SOA interfaces today, and it's not a pretty thing. The problemgrows out of a fundamental limitation, however, which is that services
exposeonly specific views into an application's data. It's as if the data is behind acurtain, with each service punching a hole in that curtain. The creator of thisinterface is forced to guess how the application's clients will want to accessthe data, deciding
in advance what holes to cut in the curtain.

Contrast this with how OData works.Rather than exposing application-defined services, it allows access to anentire application-defined data model. Clients are free to query this
model inany way they find useful. The application's creator still has control overwhat's exposed, of course, and designing the data model likely requires makingsome predictions about what clients will want. Still, exposing a data modelpulls back the curtain
on an application's data, giving clients moreflexibility in how they access it.

Not every problem that relies on SOAtoday should use OData, of course. If an application exposes a functionality-oriented set of services rather than services targeting data access,
forinstance, OData probably isn't a good choice. But for applications that wish toexpose data in a broader, more consistent way to diverse clients, using ODatacan be an attractive option.

OData Client Libraries

A developer is always free to create anOData client from scratch -- it's just code. To make life simpler, though,Microsoft and others provide a number of OData client libraries.
The currentlyavailable options include libraries for versions 3.5 and 4 of the .NETFramework, JavaScript, Silverlight, Java, PHP, Android, iOS, Windows Phone 7,and Ruby.

Microsoft also provides some toolsupport for creating OData clients in Visual Studio. For example, when adeveloper adds a reference to an OData service, Visual Studio 2010 can readthat
service's CSDL definition using the $metadata option described earlier.Once it has this information, Visual Studio will generate C# or Visual Basicclasses for working with the data this service provides. The tool can alsoprovide a graphic illustration of a
service's data model, giving the developera visualization of how data exposed by an OData service is structured.

OData Services

As with clients, creating an ODataservice from scratch is always possible. Once again, though, relying on anexisting library can help. Java developers can use the open source odata4jtoolkit
to help do this, for example. Among other things, this toolkit providessupport for exposing data through a Java Persistence API (JPA) entity model orfrom plain old Java objects (POJOs).

For .NET developers, Microsoft providesWCF Data Services. Figure 13 shows the main parts of this technology.

As the figure shows, WCF Data Servicesincludes the OData client libraries for .NET, Silverlight, and Windows Phone 7.More relevant here, though, is its support for creating an OData
service withthe WCF Data Services framework. This framework is divided into two parts:

The Data Services runtime, whichimplements the OData protocol, parses URIs, and more. This runtime alsosupports serializing data using both Atom/AtomPub and JSON.

The Data Access layer, which handles thetranslation between the underlying data and the EDM. Different kinds of datacan use different providers to do this. The Entity Framework
provider is usedto expose relational data, such as data stored in SQL Server. The Reflectionprovider is used to expose data directly from .NET classes. For other kinds ofdata, the creator of an OData service can implement a custom provider that doesthe required
mapping.

The more data sources that supportOData, the more useful OData becomes. The goal of providing WCF Data Servicesand odata4j is to make this support easier to create.

Conclusion

Our world really is awash in data. Yettoo much of it is locked up in silos, inaccessible to many of the applicationsthat might use it. By providing a common way for diverse clients
to access anarray of data sources, OData can help set this information free.

Because it relies on a simple abstractdata model based on entities and associations, OData can be used with manykinds of data. Because it builds on familiar technologies such as
REST,Atom/AtomPub, and JSON, OData isn't especially hard to understand. And becausesupport is available for creating clients and services on various platforms anddevices, OData is straightforward to implement.

The value of a common approach toaccessing data is undeniable. Reflecting this, many clients and data sourcessupport OData today. Going forward, expect to see that support get broaderstill.
Our data is just too valuable to keep locked away.

1. Even though the EDM wasoriginally created as part of Entity Framework, OData borrows just the EDMmodeling aspect of EF. An implementation
of OData isn't required to use EFitself.

2. MERGE is a custom HTTP methodadded by OData's creators. Since then, RFC 5789 has defined the PATCH method toprovide the same functionality.
The next version of OData will support bothMERGE and PATCH.

3. Using standard symbols such as"=", "&gt;", and "+" might seem simpler, butmost of these already have a meaning in the URI syntax -- they're
not availablefor OData to use.

About the Author

David Chappell is Principal of Chappell& Associates ( www.davidchappell.com)in San
Francisco, California. Through his speaking, writing, and consulting, hehelps people around the world understand, use, and make better decisions aboutnew technologies.