2. WHAT IS ODATA
A web protocol for querying and updating
data.
Built on top of technologies like http,
AtomPub and JSON.
Enables a standardized way for data to be
available over the web.
OData is RESTful service style as SOAP is
to RPC.
3. ODATA : UNIFORMITY
Uniform way of representing structured data
– JSON & XML
Uniform URL Conventions
– Navigation, Filtering, Sorting, Paging
Uniform Operations
– GET, POST, PUT DELETE always mean the
same
5. ATOM PROTOCOL
OData is layer on top of Atom Publishing
Protocol.
Atom is simple way of exposing ‘feed’ of
data.
6. ODATA COMPONENTS
A Service definition language
Error handling
Dataset paging
Advanced Queries
Batch requests
Two request response formats : Atompub &
JSON
7. ODATA BASICS
OData is composed of feeds, which are
collections of typed entries.
Each entry represents a structured record
with a key.
Entries can be part of type hierarchy
Example :
http://services.odata.org/OData/OData.svc/Pr
oducts
8. SERVICE DOCUMENT
OData service may contain one or more
feeds.
Service document lists all top level feeds.
Sample Service Document :
http://services.odata.org/OData/OData.svc
OData service can expose service specific
operations
9. SERVICE META DOCUMENT
Service meta document describes the shape
of an OData service.
Describes the Entity Data Model (EDM) of a
given service.
Abstract data model of the resources
exposed by the service.
Sample Meta Document :
http://services.odata.org/OData/OData.svc/$
metadata
10. ENTITY DATA MODEL
EDM is the abstract data model used by the
OData Services.
EDM is independent of underlying data
persistence format or implementation.
Entities and Associations are main concepts
in EDM.
12. SERVICE OPERATIONS
OData services can expose service
operations, which are simple functions.
A service operation can accept primitive type
input parameters.
Can be defined to return a single or
collection of primitive, complex type, entries
or void.
http://services.odata.org/OData/OData.svc/G
etProductsByRating?rating=4
15. WCF DATA SERVICE
WCF Data services enables the creation and
consumption of OData services for the web.
Demo with VS2010, ADO.NET Entity Model,
Northwind DB and WCF Data Service.
16. SERVER PAGING IN DATA SERVICES
Allow the service author to limit the size of
response to a query.
For queries that exceeds size limit:
Partialresponse is returned without exceeding
the size limit.
In addition a link to get the rest of the results.
18. SHAREPOINT & ODATA
Every Sharepoint 2010 server is Data
Services server.
Supports ATOM & JSON formats.
Enables client integration with sharepoint
from any platform & any language.
19. CUSTOM DATA SERVICE PROVIDER
Data services sits on top of Data service
provider.
Entity Framework
LINQ to SQL DataContext
Custom Service Provider – IDataService
Metadata, Query, Update, Paging, Stream
Provider
For more details on custom DSP see here
20. GDATA
Google has GData protocol for accessing
Calendar, Youtube.
Limited only to Google Services.
OData is an attempt to open up server side
of the protocol.
21. CONCLUSION
Simple, Uniform way of sharing data at the
protocol level.
Enables broad integration across products
and breaks data silos.
All you need is Http stack to integrate with
any OData producer.
Sharepoint and Office betting on OData.
ODATA enables the creation of RESTful based data services that allow resources identified using URL and defined in a data model to be published and edited by web clients using HTTP messages.OData is the web-based equivalent of ODBC, OLEDB, ADO.NET and JDBC.http://msdn.microsoft.com/en-us/library/ff478141.aspx
As more data-oriented web APIs come online, each team responsible for the design of each web API is confronted by the same kinds of questions, and each team answers these in their own particular wayIncreasingly, “RESTful” is a design goal of web APIs. Great…but what does that mean? How do you expose the data, the relationships between the entities inside the model, and what should the querying syntax look like?Unfortunately, there are as many answers to these questions as there are RESTful web APIs. And there needn’t be. For to ODatarize your data is to RESTify your data. Do spend the time at the value layer - figure out the way your developers / consumers want to see the data and expose it that way. Do make it easy for devs / consumers to learn / navigate about the data and use it. Do not make them learn about the unique idiosyncrasies you’ve built into your APIOData is web equivalent of ODBC, OLEDB, ADO.NET
ATOM Pub is built on top of Atom Syndication Format.ATOM is XML format on which Odata is published.ATOM Pub is a protocol for getting atom data and also creating, updating and deleting it, all of which Odata relies. Odata provides features to make query and manipulation richer. ATOM is simple way of exposing ‘feed’ of data, each distinct piece of which is called ‘entry’. Atom originated in a world of bloggers to keep the readers upto date. Atom is meant to be simple: point your feed reader software, e.g. RSS Bandit or Microsoft Outlook, at the URL of an Atom service and it will tell you when there’s something new. However, if you want to publish new data, you need a whole other API, like the Metaweblog API, the WordPress API, etc. Or you can use AtomPub.
As a RESTful standard, it exposes a web service in the form of resources accessible via discrete HTTP urls, representing actions via the HTTP methods. It fills in the gaps that the REST style of architecture leaves open, giving a full specification, from the request to the response (although omitting authentication and authorisation). OData surprisingly also allows RPC-style operations as well.Service Definition Language - Providing a web-service description language, it allows automatic creation of proxy classes for clients to quickly consume with little knowledge of the service. It also allows a level of client-side validation of a request before it is sent outError handling - If an error occurs, as with the REST architecture style, OData producers will use HTTP error statuses 4xx/5xx to notify of an error, however this information is not usually enough to help the consumer bug fix, so OData defines an error message specification which is sent in the response body.Dataset paging - A frequent problem faced when building a web-service that lists entries is that it becomes a problem when the number of entries gets large. Aside from the fact that not all HTTP servers are built for long streams of data, the consumer does not need all of that information at once, so paging is required to limit the response. OData defines this ability in its specification.Batch Requests - Web services in a REST architecture tend to have limited functionality in an individual request. As such, additional resources are needed to define complex transactions. This means that the web-service needs multiple calls to different resource actions. OData improves this by allowing multiple calls to be batched into one request, removing the HTTP overhead associated.If you look at what we’ve seen in AtomPub so far, it’s clear it’s pretty close already, providing collections of entries which must have required elements and that can be extended. Also, AtomPub provides the idea of getting as well as updating and removing entries. What it doesn’t have is any idea of a data model for defining typed or untyped values on an entry (e.g. columns in a row), nor does it have any kind of a query language for getting just the entries and the data that we want[xi]. These are two of the extensions that OData adds on top of AtomPub.
At the core of OData are feeds, which are Collections of typed Entries. Each entry represents a structured record with a key that has a list of Properties of primitive or complex types. Entries can be part of a type hierarchy and may have related entries and related feeds through Links. Browse to the URL and show the xml in IE.
Simple OData services may consist of just a feed. More sophisticated services can have several feeds, and in that case it is useful to expose a service document that lists all the top-level feeds so clients can discover them and find out the addresses of each of them. For example, this URI http://services.odata.org/OData/OData.svc, identifies the service document for a sample OData service.In addition to feeds and entries, OData services can expose Service Operations, which are simple, service-specific functions that accept input parameters and return entries or complex/primitive values.As shown by the examples noted above, OData services expose all these constructs (feeds, entries, properties within entries, links, service documents, and metadata documents) via URIs in one or more representation formats, which can be acted upon (query, update, insert, delete, and so on) by clients using basic HTTP requests.
In order to help clients discover the shape of an OData service, the structure of its resources, the known links between resources, and the Service Operations exposed, an OData service may also expose a Service Metadata Document. OData metadata documents describe the Entity Data Model (EDM) for a given service, which is the underlying abstract data model used by OData services to formalize the description of the resources it exposes. For example, the URI http://services.odata.org/OData/OData.svc/$metadata identifies the metadata document for a sample OData service.SUMMARY : Service Document and Service Meta DocumentAs described above in OData Basics, expose a Service Document that lists all the top-level feeds so clients can discover them and find out the addresses of each of them. The service document is typically available at the Service Root URI and may be formatted in Atom or JSON as described in [OData: Atom] and [OData: JSON].All data services may also expose a Service Metadata Document that describes the data model (i.e. structure and organization of all the resources) exposed as HTTP endpoints by the service. The following sections describe the underlying data model used by OData services and its representation - the Service Metadata Document.
The use of the EDM as an underlying data model for the Open Data Protocol does not mandate that a particular data persistence format or implementation be used by an OData service. The only requirement to be an OData service is that the HTTP interface exposed by the service is consistent with the protocol described in this and the associated documents.Entities are instances of entity types (Customer, Employee etc) which are structured records with named and typed properties and with a key. Complex types are also contains list of properties but with no key. Exist as a property in entity Entity key is formed by subset of properties of Entity (ex : CustomerId or OrderId). Uniquely identifies instances of entity types and participates in relationships. Entities are grouped into Entity Sets (ex : Customers is a of Customer Entity Type instances)Associations defines relationship between two or more entity types (ex : Employee works for Department)Instances of Associations are grouped into Association SetsNavigation Properties are special property on Entity types which are bound to a specific association and can be used to refer to associations of an entry.Finally all instance containers (Entity Sets and Association Sets) are grouped in Entity Container.A Service Metadata Document describes the data model (i.e. structure and organization of all the resources) exposed as HTTP endpoints by the service. A Service Metadata Document describes its data in EDM terms using an XML language for describing models called the Conceptual Schema Definition Language (CSDL). CSDL is fully described in [CSDL]. When exposed by an OData service as a Service Metadata Document, the CSDL document is packed using the format described in [EDMX].
The service root URI identifies the root of an OData service. The resource identified by this URI MUST be an AtomPub Service Document (as specified in [RFC5023]) and follow the OData conventions for AtomPub Service Documents (or an alternate representation of an Atom Service Document if a different format is requested). OData: JSON Format specifies such an alternate JSON-based representation of a service document. The service document is required to be returned from the root of an OData service to provide clients with a simple mechanism to enumerate all of the collections of resources available for the data service.ExamplesThe example URIs below follow the addressing rules stated above and are based on the reference service and its service metadata document available at http://services.odata.org/OData/OData.svc/ and http://services.odata.org/OData/OData.svc/$metadata.http://services.odata.org/OData/OData.svc/Categories Identifies all Categories Collection.Is described by the Entity Set named "Categories" in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)Identifies a single Category Entry with key value 1.Is described by the Entity Type named "Categories" in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)/NameIdentifies the Name property of the Categories Entry with key value 1.Is described by the Property named "Name" on the "Categories" Entity Type in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)/ProductsIdentifies the collection of Products associated with Category Entry with key value 1.Is described by the Navigation Property named "Products" on the "Category" Entity Type in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)/Products/$countIdentifies the number of Product Entries associated with Category 1.Is described by the Navigation Property named "Products" on the "Category" Entity Type in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)/Products(1)/Supplier/Address/CityIdentifies the City of the Supplier for Product 1 which is associated with Category 1.Is described by the Property named "City" on the "Address" Complex Type in the service metadata document.http://services.odata.org/OData/OData.svc/Categories(1)/Products(1)/Supplier/Address/City/$valueSame as the URI above, but identifies the "raw value" of the City property.ExamplesThe example URIs below follow the addressing rules stated above and are based on the reference service and its service metadata document available at http://services.odata.org/OData/OData.svc/ and http://services.odata.org/OData/OData.svc/$metadata.http://services.odata.org/OData/OData.svc/Categories(1)/$links/ProductsIdentifies the set of Products related to Category 1.Is described by the Navigation Property named "Products" on the "Category" Entity Type in the associated service metadata document.http://services.odata.org/OData/OData.svc/Products(1)/$links/CategoryIdentifies the Category related to Product 1.Is described by the Navigation Property named "Category" on the "Product" Entity Type in the associated service metadata document.
http://services.odata.org/OData/OData.svc/Products?$orderby=Ratinghttp://services.odata.org/OData/OData.svc/Products?$top=5http://services.odata.org/OData/OData.svc/Categories(1)/Products?$skip=2/Suppliers?$filter=Address/City eq 'Redmond‘A URI with a $expand System Query Option indicates that Entries associated with the Entry or Collection of Entries identified by the Resource Path section of the URI must be represented inline (i.e. eagerly loaded). For example, if you want to identify a category and its products, you could use two URIs (and execute two requests), one for /Categories(1) and one for /Categories(1)/Products. The '$expand' option allows you to identify related Entries with a single URI such that a graph of Entries could be retrieved with a single HTTP request.
The OData service interface has a fixed number of operations that have uniform meaning across all the resources it can act on. These operations are retrieve, create, update and delete and they map to the GET, POST, PUT/MERGE and DELETE HTTP methods. Each of them acts on a resource that is indicated using a URI. In addition to the uniform interface operations, OData allows servers to expose custom operations (known as Service Operations) that can be invoked through GET or POST.For the Atom format there is more than one MIME type involved. Atom feeds and Entries use a content type of "application/atom+xml". However, when addressing Links or properties within an element the returned resource is just XML without the Atom Entry wrapper, and its content type is "application/xml".
"\\Windows\\Microsoft.Net\\Framework\\V3.5\\datasvcutil.exe" /out:northwind.cs /uri:“http://localhost:1234/Northwind.svc”Use Visual Studio ADO.Net Entity Framework and Data ServiceUse Datasvcutil.exe for generating the proxy classesEntity framework exposes EDM schemas for data stored in relational databases.
Page limits are a key concept if you are exposing a data service to the world and you want to ensure that clients can’t overload your service by issuing queries that require an excessive amount of resources to respond to. The paging limits also work as a built-in load balancing tool by distributing large queries over a number of smaller partial queries which will reduce the impact of large queries on the overall response times of the system. The paging has one final benefit in that it forces the developers of client apps to think about the size of the queries they are issuing against the service and smart developers can lazy-load only the pages they need in an on-demand fashion.Show the demo with :config.SetEntitySetPageSize("Customers", 1); config.SetEntitySetPageSize("Orders", 1); config.SetEntitySetPageSize("Order_Details", 2); Run the demo by showing the following link : http://localhost:61745/Northwind.svc/CustomersHighlight the next link in the response.
The SharePoint Data Service head is not just a side integration deal, it's a full-on REST-over-HTTP head for SharePoint. It supports browsing as well as modifying data using regular HTTP verbs (GET, PUT, DELETE, etc.), it does ETags for concurrency control, enforces business logic as part of side-effecting methods, and it handles the full range of Data Services conventions for URLs, Atom and JSON payload formats, etc. It also exposes full metadata like any other Astoria service, allowing Visual Studio and any other metadata-driven client to give you a great experience on the client side. Now if you need to get or manipulate data in SharePoint from any platform in any language, all you need is an HTTP stack.Show the demo at http://venknar-vm/_vti_bin/listdata.svcFootball Odata : http://www.openligadb.de/Webservices/OData.svc/
Data Services sits above a Data Service Provider, which is responsible for interacting with the underlying Data Source on behalf of the Data Service.Data Services ships with some internal providers, and makes it possible for you to create custom providers too.If you plan on putting a Data Service over the Entity Framework the answer is no you don't need to write a custom provider. Data Services has an implementation that talks to the Entity Framework in the box. This in conjunction with the Reflection Provider means you can use your LINQ to SQL DataContext just like an Entity Framework ObjectContext.If you want the added security of insulation and loose coupling from the underlying database schema to make your object model more resilient to change, use the Entity FrameworkIf you find that you need the features of entity inheritance and entity composition, use the Entity FrameworkIf you already have a large DLINQ codebase (oddly enough, I do) that is running just fine without entities, you probably don't need to spend the time to refactor out DLINQ to replace it with L2E.If you want to run LINQ queries against an object model, but your object model is a 1:1 mirror of the tables in your database, you probably don't need the EF.Not included in the chart above, ADO.NET vNext has a powerful "client-views" engine which will only get better with time and is just more incentive for adopting the new stuff.
I find this to be extremely important. A simple, uniform way of sharing data at the protocol level, and in a way that truly enables the lowest possible bar of entry, is key to enable broad integration across products and break data silos that form around applications.
The basic idea of Claims Based Auth, is that you authenticate against an Identity Provider and request an ‘access token’ which you can use to make requests against a server of protected resources.The server – essentially the gatekeeper – looks at the ‘access token’ and verifies it was issued by an Identity Provider it trusts, and if so, allows access to the resources.