Someone recently asked me this question: When a company that has been using 2 tiers wants to move to n-tier, what are the considerations for choosing WCF and STEs [or Trackable DTOs] vs. WCF Data Services?
This is a great question because it relates to a recent re-alignment of what used to be called “ADO.NET Data Services” (code-named Astoria) under the umbrella of Windows Communication Foundation (WCF), as well as the renaming of .NET RIA Services to WCF RIA Services. I’m going to steal an image from the .NET Endpoint blog, because it shows how each programming model rests on top of the infrastructure provided by WCF.
The two bottom layers should be quite familiar to anyone who uses WCF, but the diagram could mistakenly lead you to the conclusion that the programming model section is independent of the underlying Service Model and Channel layers. The truth is that RIA Services rests on Data Services, which is turn sits on top of Web HTTP Services (aka REST), which is tightly coupled to HTTP as a transport and XML, Atom or Json as a format. Only SOAP Services (leaving Workflow Services aside for the moment) can be used with any format and transport protocol.
Practically speaking, what this means is that there is a fork in the road when it comes to deciding how to implement an n-tier application architecture. WCF SOAP Services (that is, traditional WCF) offers the most flexibility when it comes to selecting an underlying transport. For example, I may want to use a NetMsmqBinding with clients and services that are occasionally connected. The other way to go is to select a REST-based programming model, which leverages the universality of the HTTP protocol and uses a URI addressing scheme. If flexibility concerning the transport layer matters to you, then traditional SOAP-based WCF services are the way to go.
Another differentiating factor is that WCF SOAP Services tend to be operation-based, while REST services are said to be resource-based. That means clients are effectively going to call methods on a SOAP service, while client of a REST service are going to send HTTP requests (mostly GET’s) to a URI and expect to get some resource in return, usually a blob of XML, probably in a syndication feed format such as ATOM. From an architectural perspective what this means is that service operations will be inherently more constrained than resources that are freely accessible. Whether that’s good or bad depends entirely on your point of view. If you want to design a service that is more tightly locked down, then you’ll most likely prefer a traditional WCF service. On the other hand, if you want to freely make your data available to clients (especially clients that may not understand or care about SOAP), you would get more bang for your buck with a REST-based service.
Traditional WCF services are also going to allow you a more advanced level of security (for example, message-based or federated security), and can offer reliable messaging and transactional services. That’s because WCF supports the WS-* SOAP protocols that have evolved over the last several years. On the other hand, you may not need or want any of those features. If your client is mainly an AJAX web app, or even a Silverlight rich Internet app, then REST-based services are all you need, and you can benefit from tight coupling with HTTP.
From reading this post so far, you might get the impression that I favor traditional WCF services over REST-based services. And if we were only talking about a service programming model, you might be right. But Microsoft has done a lot of work on the client-side programming model for Data Services. All you have to do for a .NET client is simply write a LINQ query, and Data Services will translate it to a URI sent to the service. The resulting XML is used to populate client-side entities, which are change-tracked. Heck, it even supports batch updating and concurrency control. Sweet. And WCF RIA Services strives for RAD n-tier development for Silverlight apps, with support for end-to-end data validation and a whole bunch of other goodies. In addition, these higher-order programming models allow you to blend in an operation-based approach by adding methods to your data service.
So I suppose your choice between SOAP and REST services will depend a great deal on the architectural objectives dictated by your application requirements. Alas, there’s still a role for the architect in all of this. 🙂
White Paper on RESTful Web Services with WCF 3.5
Scott Hanselman Interview with Pabro Castro on OData
Open Data Protocol (OData)
WCF Data Services Team Blog
Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010
Pingback: Accessing data as resources through URI - WCF Data Services - IBloggable - implemented
Nice Article , must read for architectural consideration
i wanted to check with you if you can elaborate bit more about client side programming as i bit new to this area
can you pleae provide an example on the “All you have to do for a .NET client is simply write a LINQ query, and Data Services will translate it to a URI sent to the service. The resulting XML is used to populate client-side entities, which are change-tracked. Heck, it even supports batch updating and concurrency control” . I dont need a working sample but /..just wanted to better understand how linq as applied on WCF data services and that still provides change track and bulk ops..Thanks
I presented a talk on WCF Data Services to a developer group. You can download the slides and code for it here: https://blog.tonysneed.com/2011/11/11/odata-where-art-thou. A recording of the talk can be found here: http://usergroup.tv/videos/odata-where-art-thou-publishing-odata-feeds-with-wcf-data-services.
Hope this helps!
I tony, I am really interested of Data Service hosted in a Windows Service but I don’t understand if is possible to implement some kind of authentication.
All sample I found are for SOAP, nothing about REST.
Do you know if is possible or not?
WCF Data Services uses REST, not SOAP. It’s purpose in life is to expose a data model as a REST-ful service.
In terms of security, although i haven’t done it, you might want to leverage IIS for basic authentication. It has authorization support built in, however.
Great OData presentation! I’m trying to find more information on how things looks like on the clinet side, and in particular how to handle Complex Data types. Is it correct to summarize the difference between SOAP and Data Service as: With SOAP the server package the needed information for the client, while with Data Service the client need to do that, so in fact with Data Service we have to move the Business layer to the client?
Thanks Tony. This is really very helpful and Its cleared few of my doubts. Is there any way to convert WCF REST services to SOAP based WCF services?
The beauty of WCF is that you can expose a service as BOTH a REST-based and a SOAP-based service at the same time. All you have to do is add a different endpoint for each. I happen to have a WCF SOAP – REST Simple Multi-Project Template which you can download from the Visual Studio Extensions Gallery: http://visualstudiogallery.msdn.microsoft.com/f8a6c081-60ac-41ff-b9f9-8059a5231e70. This will create a sample service exposed as both REST and SOAP.