Jump to content

WCF Data Services

From Wikipedia, the free encyclopedia
(Redirected fromADO.NET Data Services)
WCF Data Services
Original author(s)Microsoft
Initial releaseAugust 11, 2008;16 years ago(2008-08-11)
Stable release
5.6.0
Operating systemMicrosoft Windows,Linux,macOS
Websitedocs.microsoft/en-us/previous-versions/dotnet/wcf-data-services/hh487257(v=vs.103)

WCFData Services(formerlyADO.NET Data Services,[1]codename"Astoria"[2]) is a platform for whatMicrosoftcallsData Services.It is actually a combination of the runtime and aweb servicethrough which the services are exposed. It also includes theData Services Toolkitwhich lets Astoria Data Services be created from withinASP.NETitself. The Astoria project was announced atMIX2007, and the first developer preview was made available on April 30, 2007. The firstCTPwas made available as a part of theASP.NET3.5 Extensions Preview. The final version was released as part ofService Pack1 of the.NET Framework 3.5on August 11, 2008. The name change from ADO.NET Data Services to WCF data Services was announced at the 2009PDC.

Overview

[edit]

WCF Data Services exposes data, represented asEntity Data Model(EDM) objects, via web services accessed overHTTP.The data can be addressed using aREST-likeURI.The data service, when accessed via the HTTP GET method with such a URI, will return the data. The web service can be configured to return the data in either plainXML,JSONorRDF+XML.In the initial release, formats likeRSSandATOMare not supported, though they may be in the future. In addition, using other HTTP methods like PUT, POST or DELETE, the data can be updated as well. POST can be used to create new entities, PUT for updating an entity, and DELETE for deleting an entity.

Description

[edit]

Windows Communication Foundation (WCF) comes to the rescue when we find ourselves not able to achieve what we want to achieve using web services, i.e., other protocols support and even duplex communication. With WCF, we can define our service once and then configure it in such a way that it can be used via HTTP, TCP, IPC, and even Message Queues. We can consume Web Services using server side scripts (ASP.NET), JavaScript Object Notations (JSON), and even REST (Representational State Transfer).

Understanding the basics

When we say that a WCF service can be used to communicate using different protocols and from different kinds of applications, we will need to understand how we can achieve this. If we want to use a WCF service from an application, then we have three major questions:

1.Where is the WCF service located from a client's perspective? 2.How can a client access the service, i.e., protocols and message formats? 3.What is the functionality that a service is providing to the clients?

Once we have the answer to these three questions, then creating and consuming the WCF service will be a lot easier for us. The WCF service has the concept of endpoints. A WCF service provides endpoints which client applications can use to communicate with the WCF service. The answer to these above questions is what is known as the ABC of WCF services and in fact are the main components of a WCF service. So let's tackle each question one by one.

Address:Like a webservice, a WCF service also provides a URI which can be used by clients to get to the WCF service. This URI is called as the Address of the WCF service. This will solve the first problem of "where to locate the WCF service?" for us.

Binding:Once we are able to locate the WCF service, one should think about how to communicate with the service (protocol wise). The binding is what defines how the WCF service handles the communication. It could also define other communication parameters like message encoding, etc. This will solve the second problem of "how to communicate with the WCF service?" for us.

Contract:Now the only question one is left with is about the functionalities that a WCF service provides. The contract is what defines the public data and interfaces that WCF service provides to the clients.

The URIs representing the data will contain the physical location of the service, as well as the service name. It will also need to specify an EDM Entity-Set or a specific entity instance, as in respectively

http://dataserver/service.svc/MusicCollection

or

http://dataserver/service.svc/MusicCollection[SomeArtist]

The former will list all entities in theCollectionset whereas the latter will list only for the entity which is indexed bySomeArtist.

The URIs can also specify a traversal of a relationship in the Entity Data Model. For example,

http://dataserver/service.svc/MusicCollection[SomeSong]/Genre

traverses the relationshipGenre(in SQL parlance, joins with theGenretable) and retrieves all instances ofGenrethat are associated with the entitySomeSong.Simple predicates can also be specified in the URI, like

http://dataserver/service.svc/MusicCollection[SomeArtist]/ReleaseDate[Year eq 2006]

will fetch the items that are indexed bySomeArtistand had theirreleasein2006.Filtering and partition information can also be encoded in the URL as

http://dataserver/service.svc/MusicCollection?$orderby=ReleaseDate&$skip=100&$top=50

Although the presence ofskipandtopkeywords indicates paging support, in Data Services version 1 there is no method of determining the number of records available and thus impossible to determine how many pages there may be. TheOData2.0 spec adds support for the$countpath segment (to return just a count of entities) and$inlineCount(to retrieve a page worth of entities and a total count without a separate round-trip....).[3]

References

[edit]
  1. ^"Simplifying our n-tier development platform: making 3 things 1 thing".ADO.NET Data Services Team Blog. 2009-11-17.Retrieved2009-12-17.
  2. ^"ADO.NET Data Services CTP Released!".Retrieved2007-11-12.
  3. ^Archiveddocs."What's New in WCF Data Services 5.0".docs.Microsoft.RetrievedMarch 9,2019.
[edit]