31DaysOfOData

Announcing: The 31 Days of OData Blog Series

My friend and Microsoft Developer Evangelist Jeff Blankenburg has done 3 “31 days” blog extravaganzas (Silverlight, Windows Phone and now Windows Phone Mango). After talking to Jeff, I think I am crazy More »

Producing OData Screencast

OData Workshop Screencast–Producing OData Feeds

Previous Screencast — Introduction to Open Data Protocol Workshop Slidedeck — Producing OData Feeds More »

OData Protocol Screencast

OData Workshop Screencast – Introduction to Protocol

Workshop Slidedeck — Introduction to Open Data Protocol More »

31 Days Of OData – Day 5 Addressing Entities In OData

December 12, 2011   cwoodruff   3 Comments

Before we can learn about Addressing Entities in OData, we have to lay the ground work for all OData commanding including queries. We will first detail and demonstrate the Uniform Resource Identifier or URI and then look at a URI for OData.

What is a URI?

An URI is a string that is used to identify a name(URN) or a location to a resource( URL). The URN works like a name of a person or a business name where the URL functions like the physical address of a person or business.

The following are two examples of URI’s

http://services.odata.org/OData/OData.svc

http://services.odata.org/OData/OData.svc/Categories(1)/Products?$top=2&$orderby=Name

As you can see the two URI’s are both OData URI’s. The first is called the Service Root URI and the second is an OData query URI that us requesting the first two Products that are associated to Category 1 returned in alphabetical order.

Service Root URI

Every OData call must include the Service Root URI to interact with an OData feed. Think of the Service Root URI as the location of the OData feed. It represents the HTTP listener that will do the work on the behalf of the consumer of the OData feed based on the URI past the root and the HTTP Verb or Command sent.

You may discover that some OData Service Root URI’s do not end with svc. This can be accomplished with routing the request as shown in Ron Jacob’s blob post here.

Resource Path of the OData URI

The Resource Path of OData request URI functions as the resource locator from the OData consumer. It can be a request to any of the following resources of the OData protocol:

  • Single Entity (Baseball Player)
  • Collection of Entities (Baseball Players from a team and year)
  • Entity relationship between multiple Entities (Batting Statistics for a specific Baseball Player)
  • A Property of an Entity (Last Name of a Baseball Player)
  • Service Operation
  • Other resources

Query Options of the OData URI

We will work through many of the Query options during this blog series. Know that all Query Options in OData request URI’s specify three types of information:

  • System Query Options – we will explore this type in detail during this series.
  • Custom Query Options – extension point for server specific information. The Custom Query Option is always passed as a name/value pair.
  • Service Operation Parameters – used to reference a call Service Operations that reside on the OData feed.

Querying Entities

Addressing single or collections of entities located in an OData feed is akin to the FROM clause of a SQL SELECT statement along with JOINs. By allowing associations between Entities an OData request URI can reach far and wide inside the OData feed to request any shape and collection of data.

The following grammar are the rules that cover all entity query scenarios: single Entity, collection of Entities or single Property of Entity.

The areas of the OData request

Details
CollectionThe Collection will cover either a requested Collection of Entities or from a Service Collection which returns a Collection of Entities.
KeyPredicateA predicate that identifies the value(s) of the key Properties of an Entry. If the Entry has a single key Property the predicate may include only the value of the key Property. If the key is made up of two or more Properties, then its value must be stated using name/value pairs. More precisely, the syntax for a KeyPredicate is shown by the following figure.
NavPropSingleThe name of a Navigation Property defined by the Entry associated with the prior path segment. The Navigation Property must identify a single entity (that is, have a “to 1″ relationship).
NavPropCollectionSame as NavPropSingle except it must identify a Collection of Entries (that is, have a “to many” relationship).
ComplexTypeThe name of a declared or dynamic Property of the Entry or Complex Type associated with the prior path segment.
PropertyThe name of a declared or dynamic Property of the Entry or Complex Type associated with the prior path segment.

We will be looking at many ways to query and shape the data returned from an OData feed in future blog posts. Stay tuned and hope you are enjoying the series. I am working to catch up also.

Read More

31 Days of OData – Day 4 Metadata in OData

December 09, 2011   cwoodruff   1 Comment

OData-logo_biggerLet’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.

Code Snippet
  1. <?xmlversion=“1.0“encoding=“UTF8“standalone=“true“?>
  2. <edmx:Edmxxmlns:edmx=“http://schemas.microsoft.com/ado/2007/06/edmx“Version=“1.0“>
  3.     <edmx:DataServicesm:DataServiceVersion=“1.0“xmlns:m=“http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“>
  4.         <Schemaxmlns=“http://schemas.microsoft.com/ado/2008/09/edm“xmlns:d=“http://schemas.microsoft.com/ado/2007/08/dataservices“xmlns:m=“http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“Namespace=“BaseballStatsModel“>
  5.             <EntityTypeName=“Allstar“>
  6.                 <Key>
  7.                     <PropertyRefName=“playerID“/>
  8.                     <PropertyRefName=“yearID“/>
  9.                     <PropertyRefName=“lgID“/>
  10.                 </Key>
  11.                 <PropertyName=“playerID“FixedLength=“false“Unicode=“true“MaxLength=“10“Nullable=“false“Type=“Edm.String“/>
  12.                 <PropertyName=“yearID“Nullable=“false“Type=“Edm.Int16“/> <PropertyName=“lgID“FixedLength=“false“Unicode=“true“MaxLength=“2“Nullable=“false“Type=“Edm.String“/>
  13.                 <NavigationPropertyName=“Player“ToRole=“Player“FromRole=“Allstar“Relationship=“BaseballStatsModel.FK_Allstar_Player“/>
  14.             </EntityType>
  15.             <EntityTypeName=“AllstarFull“>
  16.                 <Key>
  17.                     <PropertyRefName=“playerID“/>
  18.                     <PropertyRefName=“yearID“/>
  19.                     <PropertyRefName=“gameNum“/>
  20.                 </Key>
  21.                 <PropertyName=“playerID“FixedLength=“false“Unicode=“true“MaxLength=“10“Nullable=“false“Type=“Edm.String“/>
  22.                 <PropertyName=“yearID“Nullable=“false“Type=“Edm.Int16“/> <PropertyName=“gameNum“Nullable=“false“Type=“Edm.Int16“/>
  23.                 <PropertyName=“gameID“FixedLength=“false“Unicode=“true“MaxLength=“12“Nullable=“true“Type=“Edm.String“/>
  24.                 <PropertyName=“teamID“FixedLength=“false“Unicode=“true“MaxLength=“3“Nullable=“true“Type=“Edm.String“/>
  25.                 <PropertyName=“lgID“FixedLength=“false“Unicode=“true“MaxLength=“2“Nullable=“true“Type=“Edm.String“/>
  26.                 <PropertyName=“GP“Nullable=“true“Type=“Edm.Int16“/> <PropertyName=“startingPos“Nullable=“true“Type=“Edm.Int16“/>
  27.                 <NavigationPropertyName=“Player“ToRole=“Player“FromRole=“AllstarFull“Relationship=“BaseballStatsModel.FK_AllstarFull_Player“/>
  28.             </EntityType>
  29.             …
  30.             <EntityTypeName=“PitchingTotals“>
  31.                 <Key>
  32.                     <PropertyRefName=“playerID“/>
  33.                 </Key>
  34.                 <PropertyName=“playerID“FixedLength=“false“Unicode=“true“MaxLength=“10“Nullable=“false“Type=“Edm.String“/>
  35.                 <PropertyName=“W“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“L“Nullable=“true“Type=“Edm.Int32“/>
  36.                 <PropertyName=“G“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“GS“Nullable=“true“Type=“Edm.Int32“/>
  37.                 <PropertyName=“CG“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“SHO“Nullable=“true“Type=“Edm.Int32“/>
  38.                 <PropertyName=“SV“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“IPouts“Nullable=“true“Type=“Edm.Int32“/>
  39.                 <PropertyName=“H“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“ER“Nullable=“true“Type=“Edm.Int32“/>
  40.                 <PropertyName=“HR“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“BB“Nullable=“true“Type=“Edm.Int32“/>
  41.                 <PropertyName=“SO“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“BAOpp“Nullable=“true“Type=“Edm.Double“/>
  42.                 <PropertyName=“IBB“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“WP“Nullable=“true“Type=“Edm.Int32“/>
  43.                 <PropertyName=“HBP“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“BK“Nullable=“true“Type=“Edm.Int32“/>
  44.                 <PropertyName=“BFP“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“GF“Nullable=“true“Type=“Edm.Int32“/>
  45.                 <PropertyName=“R“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“SH“Nullable=“true“Type=“Edm.Int32“/>
  46.                 <PropertyName=“SF“Nullable=“true“Type=“Edm.Int32“/> <PropertyName=“GIDP“Nullable=“true“Type=“Edm.Int32“/>
  47.             </EntityType>
  48.             <AssociationName=“FK_Allstar_Player“>
  49.                 <EndType=“BaseballStatsModel.Player“Multiplicity=“1“Role=“Player“/> <EndType=“BaseballStatsModel.Allstar“Multiplicity=“*“Role=“Allstar“/> <ReferentialConstraint>
  50.                     <PrincipalRole=“Player“>
  51.                         <PropertyRefName=“playerID“/>
  52.                     </Principal> <DependentRole=“Allstar“>
  53.                         <PropertyRefName=“playerID“/>
  54.                     </Dependent>
  55.                 </ReferentialConstraint>
  56.             </Association>
  57.             <AssociationName=“FK_AllstarFull_Player“>
  58.                 <EndType=“BaseballStatsModel.Player“Multiplicity=“1“Role=“Player“/> <EndType=“BaseballStatsModel.AllstarFull“Multiplicity=“*“Role=“AllstarFull“/> <ReferentialConstraint>
  59.                     <PrincipalRole=“Player“>
  60.                         <PropertyRefName=“playerID“/>
  61.                     </Principal> <DependentRole=“AllstarFull“>
  62.                         <PropertyRefName=“playerID“/>
  63.                     </Dependent>
  64.                 </ReferentialConstraint>
  65.             </Association>
  66.             …
  67.             <AssociationName=“FK_TeamsHalf_Teams“>
  68.                 <EndType=“BaseballStatsModel.Team“Multiplicity=“1“Role=“Team“/> <EndType=“BaseballStatsModel.TeamHalf“Multiplicity=“*“Role=“TeamHalf“/> <ReferentialConstraint>
  69.                     <PrincipalRole=“Team“>
  70.                         <PropertyRefName=“yearID“/>
  71.                         <PropertyRefName=“lgID“/>
  72.                         <PropertyRefName=“teamID“/>
  73.                     </Principal> <DependentRole=“TeamHalf“>
  74.                         <PropertyRefName=“yearID“/>
  75.                         <PropertyRefName=“lgID“/>
  76.                         <PropertyRefName=“teamID“/>
  77.                     </Dependent>
  78.                 </ReferentialConstraint>
  79.             </Association>
  80.         </Schema>
  81.         <Schemaxmlns=“http://schemas.microsoft.com/ado/2008/09/edm“xmlns:d=“http://schemas.microsoft.com/ado/2007/08/dataservices“xmlns:m=“http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“Namespace=“BaseballStatsOData“>
  82.             <EntityContainerName=“BaseballStatsEntities“xmlns:p7=“http://schemas.microsoft.com/ado/2009/02/edm/annotation“m:IsDefaultEntityContainer=“true“p7:LazyLoadingEnabled=“true“>
  83.                 <EntitySetName=“Allstar“EntityType=“BaseballStatsModel.Allstar“/>
  84.                 <EntitySetName=“AllstarFull“EntityType=“BaseballStatsModel.AllstarFull“/>
  85.                 …
  86.                 <EntitySetName=“PitchingTotals“EntityType=“BaseballStatsModel.PitchingTotals“/>
  87.                 <AssociationSetName=“FK_Allstar_Player“Association=“BaseballStatsModel.FK_Allstar_Player“>
  88.                     <EndRole=“Player“EntitySet=“Player“/>
  89.                     <EndRole=“Allstar“EntitySet=“Allstar“/>
  90.                 </AssociationSet>
  91.                 <AssociationSetName=“FK_AllstarFull_Player“Association=“BaseballStatsModel.FK_AllstarFull_Player“>
  92.                     <EndRole=“Player“EntitySet=“Player“/>
  93.                     <EndRole=“AllstarFull“EntitySet=“AllstarFull“/>
  94.                 </AssociationSet>
  95.                 …
  96.                 <AssociationSetName=“FK_TeamsHalf_Teams“Association=“BaseballStatsModel.FK_TeamsHalf_Teams“>
  97.                     <EndRole=“Team“EntitySet=“Team“/>
  98.                     <EndRole=“TeamHalf“EntitySet=“TeamHalf“/>
  99.                 </AssociationSet>
  100.             </EntityContainer>
  101.         </Schema>
  102.     </edmx:DataServices>
  103. </edmx:Edmx>

OData Model

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

Code Snippet
  1. <SchemaNamespace=“”>
  2.     <EntityTypeName=“”>
  3.         <Key>
  4.             <PropertyRefName=“”/>
  5.         </Key>
  6.         <PropertyName=“”Type=“Edm.String“/>
  7.         <NavigationPropertyName=“”ToRole=“”FromRole=“”Relationship=“”/>
  8.     </EntityType>
  9.     …
  10.     <AssociationName=“”>
  11.         <EndType=“”Multiplicity=“1“Role=“”/>
  12.         <EndType=“”Multiplicity=“*“Role=“”/>
  13.         <ReferentialConstraint>
  14.             <PrincipalRole=“”>
  15.                 <PropertyRefName=“”/>
  16.             </Principal>
  17.             <DependentRole=“”>
  18.                 <PropertyRefName=“”/>
  19.             </Dependent>
  20.         </ReferentialConstraint>
  21.     </Association>
  22.     …
  23. </Schema>

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:

Code Snippet
  1. <Schemaxmlns=“http://schemas.microsoft.com/ado/2008/09/edm“xmlns:d=“http://schemas.microsoft.com/ado/2007/08/dataservices“xmlns:m=“http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“Namespace=“MyOData“>
  2.     <EntityContainerName=“MyEntities“xmlns:p7=“http://schemas.microsoft.com/ado/2009/02/edm/annotation“m:IsDefaultEntityContainer=“true“p7:LazyLoadingEnabled=“true“>
  3.         <EntitySetName=“Entity1“EntityType=“ODataModel.Entity1“/>
  4.         <EntitySetName=“Entity2“EntityType=“ODataModel.Entity2“/>
  5.         …
  6.         <EntitySetName=“ODataModel“EntityType=“ODataModel.EntityN“/>
  7.         <AssociationSetName=“FK_Entity1_Entity2“Association=“ODataModel.FK_Entity1_Entity2“>
  8.             <EndRole=“Entity1“EntitySet=“Entity1“/>
  9.             <EndRole=“Entity2“EntitySet=“Entity2“/>
  10.         </AssociationSet>
  11.         …
  12.         <AssociationSetName=“FK_Entity1_EntityN“Association=“ODataModel.FK_Entity1_EntityN“>
  13.             <EndRole=“Entity1“EntitySet=“Entity1“/>
  14.             <EndRole=“EntityN“EntitySet=“EntityN“/>
  15.         </AssociationSet>
  16.     </EntityContainer>
  17. </Schema>

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?

imageWhen 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:

AddServiceRefence

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.

AddServiceRefenceWizard

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.

Read More

31 Days of OData – Day 3 OData Entity Data Model

December 04, 2011   cwoodruff   No comments

OData-logo_biggerFrom Day 2 of the series, we looked at data types that are present in the OData protocol. These data types allow for the richness of the data experience. Next we will look at taking these data types and crafting the entities that make up the OData feed.

An OData feed is very much like a database with tables, foreign keys and stored procedures. The data from an OData feed does not have to originate in a relational database but this is the first and most important type of data repository that OData can represent. The OData’s Entity Data Model (EDM) is simple but elegant in its representation of the data. It is designed to handle the data but also the relationships between entities that allow for the rich data experience we experience.

The Roadmap of the EDM

Just like a roadmap the EDM acts as a guide that allows us to travel the OData feed’s paths. It furnishes us the collections of entities and all details needed to understand the entities within its map. The EDM also gives us the paths or associations between the unique Entities of the OData feed. The ability to navigate easily without knowing much about the layout of the OData land is where OData gives us the freedom to have the Data Experiences (DX) we need for today’s solutions and consumer expectations.

The Entitles in an OData feed represents a specific type of data or Entity Type. The Entity Types of an OData feed could simulate some real world item, concept or idea such as a Book, College Course or Business Plan. The Entity Type contains properties that must adhere to the data types allowed and provided by the OData protocol or be of a Complex Type (explained later). To exist in the OData protocol, the Entity Type must be unique and so must have a unique identifier that allow for the Entities of that Entity Type to be located and used within the OData Feed. The Entity Key can be composed of one or more Entity properties and will be a unique property for the Entity Type. Most Entity Types will have a single property but that is not a requirement. An example of a multiple property Entity Type key is on my baseball stats OData feed and the Batting Entity Type.

The Batting Entity Type in my baseball stats OData feed is comprised of the following properties:
  • playerID – the Player Entity Type’s Key
  • yearID – the year of the baseball season
  • stint – baseball players could be traded and traded back to a team in the same season so needs to be tracked
  • teamID – the team the Player played for in the stint
  • lgID – the league of the team the player played for in the stint
As you can see OData can handle complex or composite Keys and allow for almost anything we give it. The collection of Entities is grouped in an Entity Set within the OData feed.
The following is an example of an Entity Type from the baseball statistics OData feed.
<EntityType Name="Player"> <Key> <PropertyRef Name="playerID"/> </Key> <Property Name="playerID" FixedLength="false" Unicode="true" MaxLength="10" Nullable="false" Type="Edm.String"/> <Property Name="hofID" FixedLength="false" Unicode="true" MaxLength="10" Nullable="true" Type="Edm.String"/> <Property Name="birthYear" Nullable="true" Type="Edm.Int16"/> <Property Name="birthMonth" Nullable="true" Type="Edm.Int16"/> <Property Name="birthDay" Nullable="true" Type="Edm.Int16"/> <Property Name="birthCountry" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="birthState" FixedLength="false" Unicode="true" MaxLength="2" Nullable="true" Type="Edm.String"/> <Property Name="birthCity" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="deathYear" Nullable="true" Type="Edm.Int16"/> <Property Name="deathMonth" Nullable="true" Type="Edm.Int16"/> <Property Name="deathDay" Nullable="true" Type="Edm.Int16"/> <Property Name="deathCountry" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="deathState" FixedLength="false" Unicode="true" MaxLength="2" Nullable="true" Type="Edm.String"/> <Property Name="deathCity" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="nameFirst" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="nameLast" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <Property Name="nameNote" FixedLength="false" Unicode="true" MaxLength="255" Nullable="true" Type="Edm.String"/> <Property Name="nameGiven" FixedLength="false" Unicode="true" MaxLength="255" Nullable="true" Type="Edm.String"/> <Property Name="nameNick" FixedLength="false" Unicode="true" MaxLength="255" Nullable="true" Type="Edm.String"/> <Property Name="weight" Nullable="true" Type="Edm.Int16"/> <Property Name="height" Nullable="true" Type="Edm.Double"/> <Property Name="bats" FixedLength="false" Unicode="true" MaxLength="1" Nullable="true" Type="Edm.String"/> <Property Name="throws" FixedLength="false" Unicode="true" MaxLength="1" Nullable="true" Type="Edm.String"/> <Property Name="debut" Nullable="true" Type="Edm.DateTime"/> <Property Name="finalGame" Nullable="true" Type="Edm.DateTime"/> <Property Name="college" FixedLength="false" Unicode="true" MaxLength="50" Nullable="true" Type="Edm.String"/> <NavigationProperty Name="Allstar" ToRole="Allstar" FromRole="Player" Relationship="BaseballStatsModel.FK_Allstar_Player"/> <NavigationProperty Name="AllstarFull" ToRole="AllstarFull" FromRole="Player" Relationship="BaseballStatsModel.FK_AllstarFull_Player"/> <NavigationProperty Name="Appearance" ToRole="Appearance" FromRole="Player" Relationship="BaseballStatsModel.FK_Appearances_Player"/> <NavigationProperty Name="AwardPlayer" ToRole="AwardPlayer" FromRole="Player" Relationship="BaseballStatsModel.FK_AwardsPlayers_Player"/> <NavigationProperty Name="AwardSharePlayer" ToRole="AwardSharePlayer" FromRole="Player" Relationship="BaseballStatsModel.FK_AwardsSharePlayers_Player"/> <NavigationProperty Name="Batting" ToRole="Batting" FromRole="Player" Relationship="BaseballStatsModel.FK_Batting_Player"/> <NavigationProperty Name="BattingPost" ToRole="BattingPost" FromRole="Player" Relationship="BaseballStatsModel.FK_BattingPost_Player"/> <NavigationProperty Name="Fielding" ToRole="Fielding" FromRole="Player" Relationship="BaseballStatsModel.FK_Fielding_Player"/> <NavigationProperty Name="FieldingOF" ToRole="FieldingOF" FromRole="Player" Relationship="BaseballStatsModel.FK_FieldingOF_Player"/> <NavigationProperty Name="FieldingPost" ToRole="FieldingPost" FromRole="Player" Relationship="BaseballStatsModel.FK_FieldingPost_Player"/> <NavigationProperty Name="Pitching" ToRole="Pitching" FromRole="Player" Relationship="BaseballStatsModel.FK_Pitching_Player"/> <NavigationProperty Name="PitchingPost" ToRole="PitchingPost" FromRole="Player" Relationship="BaseballStatsModel.FK_PitchingPost_Player"/> </EntityType> 
The OData feed can also contain Associations that define the connections (or roads from our earlier analogy) between the Entity Type and another Entity Type. An example would be the Association between a Baseball Player and his Batting Statistics. An Entity Type’s collection of Associations is called an Association Set and along with the Entity Set is assembled into an Entity Container. The Link or Navigation Property that makes up the Entity Type must act on behalf of a defined Association in the OData feed. The following is an example of what the Entity Container looks when querying the Service Metadata Document.
<EntityContainer Name="SolutionEntities" xmlns:p7="http://schemas.microsoft.com/ado/2009/02/edm/annotation" m:IsDefaultEntityContainer="true" p7:LazyLoadingEnabled="true"> <EntitySet Name="Entity1" EntityType="SolutionModel.Entity1"/> <EntitySet Name="Entity2" EntityType="SolutionModel.Entity2"/> ...
    <EntitySet Name="EntityN" EntityType="SolutionModel.EntityN"/> <AssociationSet Name="FK_Entity2_Entity1" Association="SolutionModel.FK_Entity2_Entity1"> <End Role="Entity2" EntitySet="Entity2"/> <End Role="Entity1" EntitySet="Entity1"/> </AssociationSet> <AssociationSet Name="FK_Entity1_EntityN" Association="SolutionModel.FK_Entity1_EntityN"> <End Role="Entity1" EntitySet="Entity1"/> <End Role="EntityN" EntitySet="EntityN"/> </AssociationSet> ...
    <AssociationSet Name="FK_Entity2_EntityN" Association="SolutionModel.FK_Entity2_EntityN"> <End Role="Entity2" EntitySet="Entity2"/> <End Role="EntityN" EntitySet="EntityN"/> </AssociationSet> </EntityContainer> 
A special type of structured types that can be in an OData feed is a Complex Type. The Complex Type is a collection of properties without a unique Key. This type can only be contained within an Entity Type as a property or live outside of all Entity Types as temporary data.
The last item that can be represented in the Entity Data Model is a Service Operation. We will look at the Service Operation later in the series. For now understand that Service Operations are functions that can be called on an OData feed. A Service Operation behaves similar to the Stored Procedures in a relational database.
We have looked at the Entity Data Model and what defines it in the world of OData. This will allow us to lay down a foundation for future blog posts in this series to explain the behaviors and results that we expect from our OData feeds.
 Read More
31 Days of OData – Day 2 Data Types of OData
 December 02, 2011   cwoodruff   2 Comments
OData-logo_biggerSince data is the basis for all OData feeds it is natural to see then that describing the data that represents the types Entities with in the feed is important. It is not only important for the data but also for the metadata that plays a significant role in the OData protocol.
The OData protocol is a very structured standard and with it also come a set of primitive data types. Each data type has a distinct set of properties themselves and we will look at each and understand those characteristics. Let’s dig into the list shall we?
What are the Data Types for OData?
I will give the list of primitive data types that can be used with the OData protocol and additionally I will give some of the characteristics for each type. We all should know most of these data types but it will be a good refresher.
Primitive TypesDescriptionNotesExamples
NullRepresents the absence of a valuenull
Edm.BinaryRepresent fixed- or variable- length binary dataX and binary are case sensitive. Spaces are not allowed between binary and the quoted portion. Spaces are not allowed between X and the quoted portion. Odd pairs of hex digits are not allowed.X’23AB’
Edm.BooleanRepresents the mathematical concept of binary-valued logicExample 1: true
Example 2: false
Edm.ByteUnsigned 8-bit integer valueFF
Edm.DateTimeRepresents date and time with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D.Spaces are not allowed between datetime and quoted portion. datetime is case-insensitivedatetime’2000-12-12T12:00′
Edm.DecimalRepresents numeric values with fixed precision and scale. This type can describe a numeric value ranging from negative 10^255 + 1 to positive 10^255 -12.345M
Edm.DoubleRepresents a floating point number with 15 digits precision that can represent values with approximate range of ± 2.23e -308 through ± 1.79e +308Example 1: 1E+10 Example 2: 2.029
Example 3: 2.0
Edm.SingleRepresents a floating point number with 7 digits precision that can represent values with approximate range of ± 1.18e -38 through ± 3.40e +382.0f
Edm.GuidRepresents a 16-byte (128-bit) unique identifier value’12345678-aaaa-bbbb-cccc-ddddeeeeffff’
Edm.Int16Represents a signed 16-bit integer valueExample 1: 16
Example 2: -16
Edm.Int32Represents a signed 32-bit integer valueExample 1: 32
Example 2: -32
Edm.Int64Represents a signed 64-bit integer valueExample 1: 64L
Example 2: -64L
Edm.SByteRepresents a signed 8-bit integer valueExample 1: 8
Example 2: -8
Edm.StringRepresents fixed- or variable-length character dataExample 1: ‘Hello OData’
Edm.TimeRepresents the time of day with values ranging from 0:00:00.x to 23:59:59.y, where x and y depend upon the precisionExample 1: 13:20:00
Edm.DateTimeOffsetRepresents date and time as an Offset in minutes from GMT, with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D
Where do the Data Types for OData come from?
Where do the datatypes for OData originate is a great look at the history of OData and what other products helped shape the protocol. OData originated with Microsoft so first we will look at where most data resides when developing solutions on the Microsoft stack of tools and technologies: SQL Server. When the OData protocol was announced back in 2010 most of the data types used in Microsoft SQL Server 2008 could be used to represent data in an OData feed. It would only seem logical that a technology that was developed with an organization would be shaped and influenced by the tools at hand and OData is no exception.
But that is just the start. We must also look at the Entity Framework as another key influencer in the maturation of the OData protocol. If you notice in the table above the list of the data types all have the prefix “Edm.” associated. That comes from the Entity Framework to mean “Entity Data Model”. Why is this so? It could be that other data types will be allowed at some time and that some with the same literal name could be brought into the OData protocol specification but with slightly different characteristics. If that happened these new set of primitives could conflict with the existing data types (example could be datatypes from Oracle).
The OData team was smart enough to allow for this and started using prefixes that could distinguish possibly a different representation of a string by two different database products (example could be the maximum fixed length of a string). These new data types could be given their own prefix and happily live side by side with the original data types from SQL Server and Entity Framework.
What about Spatial Data Types?
The Spatial data types that first were brought to the Microsoft world in SQL Server 2008 are a new exciting feature of both the Entity Framework 4.0 product but also for OData. These new data types are so exciting that I will be spending an entire blog post covering these later in the month. I will update and link this blog post chapter to that future post so stay tuned.
 Read More
31 Days of OData – Day 1 Background of OData
 December 01, 2011   cwoodruff   6 Comments
OData-logo_biggerWhat is the Open Data Protocol?
The official statement for Open Data Protocol (OData) is that is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. Really what that means is that we can select, save, delete and update data from our applications just like we have been against SQL databases for years. The benefit is the ease of setting up and libraries that Microsoft has created for us the developers of Windows Phone 7 Mango apps. The benefit comes from the fact that OData has a standard that allows a clear understanding of the data due to the metadata from the feed.
Behind the scenes, we send OData requests to a web server that has the OData feed through HTTP calls using the protocol for OData. You can read more about OData here.
Where did OData come from?
OData started back in 2007 at the second Microsoft MIX conference. The announcement was an incubation project codenamed Astoria. The purpose of Project Astoria was to find a way to transport data across HTTP in order to architect and develop web based solutions more efficiently. Not until after the project had time to incubate did the OData see patterns occurring that led them to see the vision of the Open Data Protocol. The next big milestone was the 2010 Microsoft MIX Conference where OData was officially announced and proclaimed to the world as a new way to handle data. The rest is history.
Building OData on the Shoulders of Web Protocols
One of the great features of the OData protocol is the use of existing and mature standards. The OData team I feel did a great job identifying and using existing technologies to build upon. The following are the technologies, standards and/or existing protocols that were used in the development of OData:
Really nothing much can be done on the Internet without HTTP so why wouldn’t OData use HTTP for its transport? Most web developers know about HTTP (or should know) so I will not dull you with details.
Most people know that Atom is used with RSS feeds to aggregate the content to others through HTTP. What you may not have known is how similar a RSS feed is to a database.
    • The RSS Feed is a collection of blog posts which can be seen as a Database and a table. Databases I know contain multiple tables so that is that are where OData builds it beyond Atom where it has multiple collections of typed Entities.
    • A Blog post inside a RSS feed is similar to a record in a Database table. The blog post has properties like Title, Body and Published Date. These properties can be seen as columns of a database table.
  • REST (Representational state transfer)
OData was developed to follow the definition of REST. A RESTful web service or RESTful web API is a web service implemented through HTTP and the principles of REST. It is a collection of resources, with four defined aspects:
    • the base URI for the web service, such as http://example.com/resources/
    • the Internet media type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid Internet media type.
    • the set of operations supported by the web service using HTTP methods (e.g., GET, PUT, POST, or DELETE).
    • The API must be hypertext driven.
What will come with the OData Blog Series?
I hope this blog series will give the community and my readers a new perspective of the OData protocol. We will cover in depth the different areas of the protocols such as datatypes, query options and vocabularies. At the end of the series I hope to have answered many of your questions and also started getting you to identify areas and solutions where OData could add benefits to your solutions, services and products.
I also hope it will raise more questions about OData that I or others can answer and generate new ideas that can add more appeal and features to this exciting protocol.
Being a Data Experience (DX) Expert
At the end of the blog series I hope I will also make more of you Data Experience Experts. That is a new term I think I coined some time ago. What is a Data Experience Expert? Well User Experience is defined in Wikipedia as:
User experience (UX) is the way a person feels about using a product, system or service. User experience highlights the experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership, but it also includes a person’s perceptions of the practical aspects such as utility, ease of use and efficiency of the system.
Based on the UX definition we could define DX as:
Data experience (DX) is the way a person feels about using data. Data experience highlights the experiential, affective, meaningful and valuable aspects of data interchanges, but it also includes a person’s perceptions of the practical aspects such as ease of use and efficiency of the data and data transportation.
I do hope you will find this definition valuable as you gain more experience with OData and other Data technologies to also pin the title of DX expert to your resume.
 Read More
Announcing: The 31 Days of OData Blog Series
 November 19, 2011   cwoodruff   7 Comments
 31DaysOfOData
OData-logo_biggerMy friend and Microsoft Developer Evangelist Jeff Blankenburg has done 3 “31 days” blog extravaganzas (Silverlight, Windows Phone and now Windows Phone Mango). After talking to Jeff, I think I am crazy enough to do one of these blog series myself and will be doing the 31 Days of OData in December. Each blog post will cover a topic in the OData protocol. I will not be covering the implementation of OData using a specific technology like WCF Data Services. These blog post will cover only the protocol itself and I hope to shed new light on the protocol for technologists in the community.
Wish me luck! (Maybe in January 2012 I will do another 31 Days and cover Producing and Consuming OData topics.)
DateTitle
December 1Day 1: Background of OData
December 2Day 2: Data Types in OData
December 3Day 3: OData Entity Data Model
December 4Day 4: Metadata in OData
December 5Day 5: Addressing Entities in OData
December 6Day 6: Addressing Links between Entities in OData
December 7Day 7: OrderBy Query Option in OData
December 8Day 8: Filter Query Option in OData
December 9Day 9: Expand Query Option in OData
December 10Day 10: Select Query Option in OData
December 11Day 11: Top Query Option in OData
December 12Day 12: Skip Query Option in OData
December 13Day 13: Format Query Option in OData
December 14Day 14: Inlinecount Query Option in OData
December 15Day 15: Custom Query Options in OData
December 16Day 16: Service Operations in OData
December 17Day 17: Error Conditions in OData
December 18Day 18: Return Formats in OData
December 19Day 19: Versioning in OData
December 20Day 20: Batch Processing in OData
December 21Day 21: Retrieving Data in OData
December 22Day 22: Creating Entities in OData
December 23Day 23: Updating Entities and Entity Properties in OData
December 24Day 24: Deleting Entities in OData
December 25Day 25: Actions in OData
December 26Day 26: Manipulating Links between Entities in OData
December 27Day 27: AtomPub Return Format in OData
December 28Day 28: Json Return Format in OData
December 29Day 29: Vocabularies in OData
December 30Day 30: Geospatial in OData
December 31Day 31: The future of the OData Protocol
 Read More
How to add a Custom Ringtone to your Windows Phone 7 Mango phone
 November 10, 2011   cwoodruff   1 Comment
We have all wanted to have custom ringtones in Windows Phone 7 since it was first released but now we can! The Windows Phone 7 Mango release offers users to add and quickly get ringtones on their phones.
Example is the Deep Fried Bytes ringtone on our podcast site here. Download the mp3 to the root of your music folder set up for your Zune Software.
image
Next open Zune Software and you should find the mp3 located in your music collection.
image
Right click on the mp3 inside Zune Software  and choose Edit to change the metadata for the mp3. Set the Genre to “Ringtone”
image
Finally press OK and drag the mp3 to your phone inside Zune Software, allow to sync and you should have the file to be an option for your Windows Phone 7 Mango device. Happy Ringtones!!
image
 Read More
Windows 8 Is Not Really About the Tablet (in the long run)
 October 04, 2011   cwoodruff   No comments
I was at the BUILD conference last month and spent a lot of time chatting and debating with many of the attendees and also with some Microsoft employees. In the end I think Windows 8 is beyond the tablet with ARM CPU support and better kernel features. I know these are not sexy but they will get Windows on all devices and across all platforms. The key to this all is that we will have one kernel to develop against for everything from phones to the XBox on our TV’s. We will have the ability to develop great UX without the issues of different OS’s like in the past with Windows CE.
We will see a future where this one kernel will be in all places where we need it: from cars to the Cloud. In the short term, the key is to fight off the iPad and Android tablet competition but we all need to look beyond this current consumer buzz and look at where Microsoft is taking us for the long marathon. Do I think there is a vision that Microsoft is not vocalizing yet? I do and this has been discussed with Windows on 3 Screens. Not much is heard of this decree these days but if we look at the OS for each screen in the past it was Windows (desktop), Windows CE (embedded and mobile) and finally a custom OS for XBox360. This will be streamlined into a new kernel that will appear with Windows 8. The Windows 8 kernel will allow developers, OEM’s and ISV’s the ability to exploit all types of device features and capabilities to the same software.
In 10 years do I think people will look back and see Windows 8 a great Microsoft release? Yes but I think it will be looked at the day when a single kernel unified the developer and hardware makers under one banner.
 Read More
Post-Thanksgiving Florida Mobility/Windows Phone Speaking Tour
 September 26, 2011   cwoodruff   No comments
Some of the great people in Central Florida asked me to speak on some Mobility, Data and Windows Phone topics the week after Thanksgiving. Seeing that I live in Michigan and the weather after Thanksgiving starts to get cold and we may even get some lake-effect snow I jumped on to speak to the Florida developers. After a week of chatting with the user groups leaders we have the schedule set and I am looking forward to meeting as many greats Florida devs.
I will be updating this blog with more details about each speaking meeting.
 Read More
Microsoft //BUILD Conference Webinar #4 – How Windows 8 Will Leverage Windows Azure
 September 23, 2011   cwoodruff   No comments
Date: October 20, 2011
Time: 1:00-2:00 PM EST
Register Now! http://microsoftbuild4.eventbrite.com/
microsoftpic
During the week of September 12, 2011, Microsoft announced ground-breaking news at their BUILD conference in Anaheim, CA. Much was learned from Microsoft in regards to their Cloud strategies.
The secret to this new revolutionary Windows Operating System is that the Cloud is integrated into Windows 8 and Windows 8 Server. Windows Azure has been a tool in developers and IT Pros belts to build great solutions on top of Windows in the past. Now Microsoft has placed those features natively into Windows 8 and Windows Server 8 to have even better Cloud extensions and interoperability.
I attended the BUILD conference and many of the Windows 8 developers sessions regarding this exciting upcoming Windows release. In the fourth and final webinar in this four-part series, I will outline the new Windows Azure features and how Windows 8 and Windows Server 8 will give developers, IT Pros and Windows users the benefits and features of leveraging Azure in their solutions.
 Read More
 Page 1 of 1712345...10...Last »
  •  
  
   
Powered by WordPress | Designed by: Email Search
  
Page optimized by WP Minify WordPress Plugin