locked
How do I extend WCF data service? RRS feed

  • Question

  • I should say from the start, I have only relatively recently started studying all this.

    OK, I am getting a little confused by what I am seeing WRT WCF data services VS WCF services.  I am finding making both (following the examples in, e.g. the walkthroughs, but it isn't clear how best to make either do what I require.

    First, it is trivially easy to make the ADO.NET entity model, and to have it recognized by both a WCF service and a WCF Data service. 

    With a regular WCF service, it was easy to see how to specify the data and operation contract, and I attempted to make a function that would get a particular entity based on whatever ID was passed as an argument.  But I couldn't figure out how to tell that function about the relevant entity collection to get the desired entity from. 

    On the other hand, with the WCF Data service, I can not see how I can add a new operation contract, let alone tell it how/where to get the entity desired.

    And I will have to do a little more than get a particular entity.  The data model actually has 3 entity collections, and while I need to be able to get precisely one entity from the first collection, and a set of entities from the second and third collections.  And to make matters more "interesting", there is relevant data in a second schema (which exists for historical reasons only - combining it with the first schema would be a huge effort in itself, not to mention that that would require changing a fair number of client applications).  So, I assume I will have to make a second WCF (Data) service to get at that data, and handle relating the two sets of data in code (I actually have code that handles this in an existing WinForms app that uses ADO.NET).

    I have a related question, but I am not sure this is the right forum.  I need to make a custom tree control for a Silverlight application, and one of the uses for this WCF service I am trying to make is that once a user logs in, the user's identity tells me what entity I need to get from the first collection in my entity model, and then this information, along with entities from the other two collections tells me what data to put in my tree control (imagine a person with accounts at several banks  and several accounts in each bank - that provides a very simplistic data model analogous to what I have to work with).

    So, should I be using a WCF Data Service, or a regular WCF service?  And then how to I add to the service a function that gets me what I need (which is ALWAYS a tiny subset of the data in the relevant DB tables)?  I should say this database is quite large and each "main entity" in my first collection for this service is a filter on all requests for data from all of the hundreds of tables in this schema.  Another concern I have is whether or not these WCF services are sensible enough to keep the data from different sessions separate (I don't want one user to see data only a different user who happens to be logged on at the same time is authorized to see); but maybe that ought to be a separate thread.

    Thanks

    Ted

    Wednesday, November 17, 2010 9:24 PM

Answers

  • Hello, to put it short, WCF Data Services is a kind of WCF (REST) Services that uses OData protocol. Read the rest if you want to learn more.

    There're two kinds of web services: SOAP and REST. SOAP is operation oriented. One advantage of SOAP is there's a single standard. Thus IDEs can build tools to parse a standard compliant WSDL document, and generated a proxy class for the particular platform. In Visual Studio, you do so by adding a service reference. You can find similar tools for serveral third party platforms, such as NetBeans, Rational Application Developer, etc. But this also means there're a lot of limitations imposed by SOAP standard. For one thing, SOAP messages could be fairly large. And without a tool to generate client proxies, it is very difficult to access a SOAP service. This locks you to a particular IDE. SOAP is usually used for business applications where clients are usually under control by the company.

    REST is usually resource oriented (although it can also be operation oriented as REST is more agile). There's no single standard, except for you have to use HTTP. The advantage is you can use any format you like (xml, JSON, binary), and even if you use xml, you don't have to follow a particular format. The disadvantage is, of course, there's no tool to build client proxies. To access a REST service, you create HTTP requests (in .NET, use WebClient or HttpWebRequest/Response). Those APIs are fairly easy to use. But they don't take care of message serializing/deserializing. So as a client software developer, if the REST service returns simple data, you will find it easier to use than SOAP. But if the REST service returns complex data, usually you must do additional work to deserialize the data. In the long run, most web/cloud APIs will be REST based, as it is more agile. For example, Windows Azure storage/management API are also REST based. REST is also used to perform operations that are inefficient in SOAP (such as file uploading/downloading).

    OData aims to make REST as simple as SOAP for client software developers, while keep the agility of REST. It defines a set of standards to standardize data format and operation contracts. The data format can be either AtomPub or JSON. If you choose JSON, you must follow a set of rules to format the data. The standard format makes it easy to build client libraries for certain platforms. You can find a lot of OData client libraries on http://www.odata.org/developers/odata-sdk, some of which are already built-into .NET/Silverlight. To keep the agility of REST, OData requires services to support extensively query mechanism. Services should not pre-define query operations. Clients can issue all kinds of queries: Fiter by name only, filter by name and date, filter by date only, filter by name and date and order the results by date, do not return the date property in the results, etc. Service must be able to handle all those requests.

    So OData makes client software developer's life much easier, while makes services much more difficult to write. This is where WCF Data Services come to play. WCF Data Services is the first service fully compatable with OData. The good news is it takes care of almost everything for you. As you can find in the tutorials, in most cases, you only need to modify one line of code, and the service is ready. And since WCF Data Services is a kind of WCF REST Services, you can still define custom operations as in a normal REST service. Other WCF features, such as message inspectors, work fine, too. Additionally, you can use all kinds of data sources. By default it uses Entity Framework to access data. But it is not difficult to write a reflection provider to use your own data source. Our team once wrote a blog post on how to create a simple reflection provider that supports full CRUD.

    Today OData is widely used accross Microsoft products. To name a few: Excel PowerPovit, SharePoint, Windows Azure table storage, SQL Azure OData labs, and so on. It is also used by several third party service providers, like Netflix.

    Another WCF service that partially supports OData is WCF RIA Services. It is operation oriented, meaning it doesn't have the agility of REST. It is usually used to make Silverlight applications as easy to develop as traditional N-tire solutions, if you don't need SOA.

    So to conclude, WCF Data Services is the best choice if you want to provide an easy to use API for your clients to work with your data (either clients built by yourself or third party clients). But it only deals with data. If you're looking for an operation oriented solution but do not need SOA, you can choose WCF RIA Services (works best with Silverlight clients, but also works with other clients). If you want to adopt SOA, you can create normal WCF SOAP Services. If you need file upload/download operations, you can use WCF REST Services. Also choose REST if you want to provide a web/cloud API that is not compatable with OData.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yi-Lun Luo Wednesday, December 1, 2010 8:58 AM
    Friday, November 19, 2010 2:04 AM

All replies

  • Hello, to put it short, WCF Data Services is a kind of WCF (REST) Services that uses OData protocol. Read the rest if you want to learn more.

    There're two kinds of web services: SOAP and REST. SOAP is operation oriented. One advantage of SOAP is there's a single standard. Thus IDEs can build tools to parse a standard compliant WSDL document, and generated a proxy class for the particular platform. In Visual Studio, you do so by adding a service reference. You can find similar tools for serveral third party platforms, such as NetBeans, Rational Application Developer, etc. But this also means there're a lot of limitations imposed by SOAP standard. For one thing, SOAP messages could be fairly large. And without a tool to generate client proxies, it is very difficult to access a SOAP service. This locks you to a particular IDE. SOAP is usually used for business applications where clients are usually under control by the company.

    REST is usually resource oriented (although it can also be operation oriented as REST is more agile). There's no single standard, except for you have to use HTTP. The advantage is you can use any format you like (xml, JSON, binary), and even if you use xml, you don't have to follow a particular format. The disadvantage is, of course, there's no tool to build client proxies. To access a REST service, you create HTTP requests (in .NET, use WebClient or HttpWebRequest/Response). Those APIs are fairly easy to use. But they don't take care of message serializing/deserializing. So as a client software developer, if the REST service returns simple data, you will find it easier to use than SOAP. But if the REST service returns complex data, usually you must do additional work to deserialize the data. In the long run, most web/cloud APIs will be REST based, as it is more agile. For example, Windows Azure storage/management API are also REST based. REST is also used to perform operations that are inefficient in SOAP (such as file uploading/downloading).

    OData aims to make REST as simple as SOAP for client software developers, while keep the agility of REST. It defines a set of standards to standardize data format and operation contracts. The data format can be either AtomPub or JSON. If you choose JSON, you must follow a set of rules to format the data. The standard format makes it easy to build client libraries for certain platforms. You can find a lot of OData client libraries on http://www.odata.org/developers/odata-sdk, some of which are already built-into .NET/Silverlight. To keep the agility of REST, OData requires services to support extensively query mechanism. Services should not pre-define query operations. Clients can issue all kinds of queries: Fiter by name only, filter by name and date, filter by date only, filter by name and date and order the results by date, do not return the date property in the results, etc. Service must be able to handle all those requests.

    So OData makes client software developer's life much easier, while makes services much more difficult to write. This is where WCF Data Services come to play. WCF Data Services is the first service fully compatable with OData. The good news is it takes care of almost everything for you. As you can find in the tutorials, in most cases, you only need to modify one line of code, and the service is ready. And since WCF Data Services is a kind of WCF REST Services, you can still define custom operations as in a normal REST service. Other WCF features, such as message inspectors, work fine, too. Additionally, you can use all kinds of data sources. By default it uses Entity Framework to access data. But it is not difficult to write a reflection provider to use your own data source. Our team once wrote a blog post on how to create a simple reflection provider that supports full CRUD.

    Today OData is widely used accross Microsoft products. To name a few: Excel PowerPovit, SharePoint, Windows Azure table storage, SQL Azure OData labs, and so on. It is also used by several third party service providers, like Netflix.

    Another WCF service that partially supports OData is WCF RIA Services. It is operation oriented, meaning it doesn't have the agility of REST. It is usually used to make Silverlight applications as easy to develop as traditional N-tire solutions, if you don't need SOA.

    So to conclude, WCF Data Services is the best choice if you want to provide an easy to use API for your clients to work with your data (either clients built by yourself or third party clients). But it only deals with data. If you're looking for an operation oriented solution but do not need SOA, you can choose WCF RIA Services (works best with Silverlight clients, but also works with other clients). If you want to adopt SOA, you can create normal WCF SOAP Services. If you need file upload/download operations, you can use WCF REST Services. Also choose REST if you want to provide a web/cloud API that is not compatable with OData.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yi-Lun Luo Wednesday, December 1, 2010 8:58 AM
    Friday, November 19, 2010 2:04 AM
  • I would completely disagree with this statement.

    " WCF Data Services is the first service fully compatable with OData."

    I have found on many occasions that it missing the compatibility mark.  Two examples I can think of off the top of my head are related to Navigation Properties.

    You cannot $filter on a navigationproperty.property nor can you orderby on a navigationProperty.property.  This is clearly stated in the Odata protocol even on links from the MS site that point back to the official Odata site.  Do you have some sort of answer to this?

    http://www.odata.org/developers/protocols/uri-conventions#OrderBySystemQueryOption

    example (notice the navigation's property used in the order by):

    http://services.odata.org/OData/OData.svc/Products?$orderby=Rating,Category/Name desc

    Thursday, January 6, 2011 4:43 PM