WCF Data Services implementation strategies

Question

Microsoft has done a savvy job of not outlining the actual place for data services in the wonderful world of SOA/Web dev.

So my question is are WCF Data Services designed to be used via external clients? Has anyone ever heard of someone using them on the server side (i.e. data base access for web service)?

Simple scenario a general layered architecture using BO business objects (parenthesis indicate what is being passed between layers)

(XML) WCF Service -> (BO)Business Logic -> (BO) Dao -> Entity Framework

or using data services it would be where DS BO are modeled business entities to be used in data service.

(XML) WCF Service ->(BO) Business Logic -> (BO) WCF Data Service -> (DS BO)Server

I can't see a use for the later, unless there are going to be a lot of cases people would be accessing your data via your Data Service Layer vs the Service layer?

Thoughts anyone, any type of reference doc that would help back it would be useful.

I am looking for pros/cons to help other people out there like me define when/where to use data services.

Answer 1

Do not do the second.

The WCF Data Services interface is based on Atom Pub, which is based on REST which is intended to be client facing.

Here is one key reason. You cannot do two-phase-commit transactions over a WCF Data Service interface and I hope the WCF team never try to enable it.

WCF Data Services is about exposing data to a remote client, not as a layer in an architecture.

Answer 2

Here is my attempt to outline everything i have found on this subject.

The purpose of Data Services are to expose some type of resource via a web URI. All data is access/changed via standard HTTP verbs (GET, POST, PUT, DELETE).

The standard response for a DS (completely configurable) are JSON/Atom.

The out of the box style of data services are designed to be the back end access layer for any type of client that needs to access its data across the web.

Data Services support adding additional business logic(through service operations/interceptors) but generally are used in cases where business logic is limited.

In summary Data Services are designed to be client facing, you are exposing your data so it can be accessed over the web from some other body. While you could force data services to fit into a back-end server data access layer, you should only do so if you can find a justifiable reason to do so. With data services come a lot of unnecessary overhead performance and coding.

I have not found any resources(blogs or articles) suggesting that these be used as a dao layer on server side applications.

Cases for using Data Service on the server side:

1) Easier to version data services. I can release varying versions of an entity model without affecting everyone that uses it (one could argue that you could do the same with a little more work just using a ADO.NET Entity model)

2) Want the ability to access data at a lower level. You are allowing a back door access into your database. In a high level you are exposing a Business Service, and a Back Door Data Accesses Service. There could exist a case where a another domain only has a subset of shared data in its data model and needs to filter on something that is in your model. A data service would allow you to talk VIA universally via uris.

Resources

White Paper Using Microsoft ADO.NET Data Services

ADO.NET Data Services Overview

Simplifying our n-tier development platform: making 3 things 1 thing

Data Services for the Web

Answer 3

Setting up your data access layer on data services is a suicide. WCF data services are for remote clients. That's it.

Answer 4

So my question is simple, are WCF Data Services designed to be used via clients? Or has anyone ever heard of someone using them on the server side?

The Bear in mind that the term "client" has a broad meaning, and can specifically include back-end systems, so in that sense the short answer would be yes. I havenb't heard of anyone using them seerver-side, but there's no reason why not; RSS is used to syndicate data between systems, WCF Data Services would be another way of doing that.

Maybe you're looking at this from a technology centric view-point, when really you need to be thinking more holistically? WCF Data Services are simply a tool - use them where ever appropriate.

Looking at some of the high-level overview docs it looks like the WCF Data Services have a pretty broad range of possible applications.