31 Days of OData – Day 4 Metadata in OData

Let’s go back 15 years ago when I started professionally developing software and using relational databases. The relational database was a great tool to deal with data. No more did we have to use flat files to store our data with tools named Paradox, dBase and other such data management systems. We now had more flexibility to build our solutions and the new architecture pattern Client-Server that was the rage for all developers circa 1996.

Relational databases gave us the SQL language and that in turn allowed the developers of the day to quickly create, read, update and delete (CRUD) data that was stored on the server and build our applications at the client. Life was great (for me at least) because I knew nothing different. If I wanted to learn about a new database, I would get the schema either in a text file that had a set of CREATE SQL calls for all the objects that made up the database. If we were really lucky we received a printed graph of the database that gave the developers a nice graphical layout of the data tables and views with the relationships between the tables and views. It took time to understand the meaning of the database but that is what we did.
In 2007 I experienced a glimpse into the future that shook my world. It was when I started experimenting with a new incubation project from Microsoft called Astoria. I saw it at first as way to get data across HTTP and that excited me. What blew my mind after really learning about it was Metadata. Compared to the time I spent discovering the meaning and shape of the data schema of a relational database that a DBA created and handed to me, Metadata was the bridge into a new frontier.
Let’s step back and take a look at what Metadata is and how it works within OData. Metadata is defined broadly as “Data about Data”. Think of metadata as the Dewey Decimal we learned as kids when we visited the library. The card catalog does not carry the information about the content inside the books but it does describe the books and information that the books contain in a broad level to allow readers to find and locate the books they are interested in on the shelves. Metadata does the same for us as users of the data that the OData feeds allow us to consume.
In OData, the Service Metadata Document allows the consumers of the data provided by the OData feed to understand the Entity Data Model (Day 3 of the series). The Service Metadata Document does not carry any details of the data held within the data repository of the OData feed. It contains the roadmap to the data. In the SOAP world the Service Metadata Document would be the equivalent of the WSDL file. Let’s look at the structure of the Service Metadata Document (in XML) and walk through its map. We will use the Baseball Statistics OData feed found here as our example.
We first need to query the Service Metadata Document from the OData feed. How this is accomplished is my using the $metadata query option at the base of the OData feed as shown below:
http://baseball-stats.info/OData/baseballstats.svc/$metadata
The Service Metadata Document is returned in the payload after the $metadata query and has three parts: the EDMX which is made up of the OData Model and also the Entity Collection.

OData Model

The OData Model section of the Service Metadata Document has the following structure:

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

The purpose of the OData Model section is to give the detailed information for each object in the OData feed. The first objects aggregated in the OData Model are the EntityTypes with their full descriptions including the Key, Properties and NavigationProperties. Next is the set of Associations that are in the Entity Data Model. In addition each metadata type is fully described based on the data such as the EntityType’s Property details such as type, if the Property is nullable, the maximum length of the data of the property and/or many more that give us a complete view of the Property. Another example is the details of the Association which will give the entities the Association join together as well as the type of join.

Entity Collection

The Entity Collection is also part of the Service Metadata Document and it follows the OData Model in the payload that is returned from the OData feed. An example of the Entity Collection follows:

The Entity Collection does not contain the details of the Entities and Associations contained in the OData feed. It is only the references from the OData Model and gives the roadmap to quickly transverse the landscape from the OData feed. The Entity Collection is made up of the following sections:

• EntitySet
• AssociationSet

You can learn more about the Entity Collection from the third day of the blog series. I will not go through it again since it is the same content and details from that post.

Why should I love the Metadata?

When I speak and present to the community about OData, I think most people do not get the beauty of Metadata. I have a slide deck where I show an iceberg and the data is shown above the water and metadata below. I have the image in this post so you can see what I mean. I do not assume that the Metadata is larger in size or greater in importance to the Data of the OData feed. What I try to get across to the audience is that we may either not see the importance of Metadata or the power we receive from it. It really is the hidden secret of OData (and the Semantic Web).
what most developers also do not know is that is they have worked with OData within Visual Studio 2010 they have benefited from the Metadata of OData. You may ask how and if so lets look at adding a Service Reference to a VS10 project.When we need to add a reference to an OData feed into our VS10 project we usually add it through the “Add Service Reference” feature as shown below:

Going through the Wizard to allow the project access to the OData feed is not anything but the Wizard gathering the metadata from the OData feed and creating the proxy classes based on the EntityTypes from the Service Metadata Document. You can see that the Wizard after discovering the metadata from the OData feed gives us the list of the EntityTypes in the Wizard as shown below. With the proxy classes generated your application has the local Model that can be used to build, retrieve and handle the data from the OData.

Now that we have looked at the Metadata of OData, the moving parts of the Metadata Service Document and finally a real world example on how we work with the Metadata each day, I hope this gives you a little more appreciation for OData and also for the protocol.