views:

898

answers:

3

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.

+1  A: 

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.

Darrel Miller
Can you detail the two-phase-commit transaction limitation ? Are you simply talking about programatically controlling a two phase commit, or internal issues?
Nix
If you search here on REST Transactions you will see plenty of discussions of this. My answer on the subject is here http://stackoverflow.com/questions/2346964/if-transactions-over-rest-are-unachievable-how-can-rest-ever-be-really-useful
Darrel Miller
A: 

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.

Adrian K
Please take better care in your answers (spell check), as well as read the question. This answers nothing.I said in my question "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" if for some reason you are exposing two interfaces a Business Service AND a Data Service i could see a need/use for this architecture, but beyond that why would anyone go through all the hassle of using data services to access a database?Why pull out a nail gun when you are just nailing one nail?
Nix
In that case don't say your question is a simple one; I gave you my thoughts on that (first part) specifically - which you are perfectly entitled to vote down if it's not what you're after. I admit I found your second question/example a bit hard to fully understand - but then it's not always easy trying to communicate this sort of thing via written text only. I apologise for the poor spelling, but I dear say I've seen worse; I'm assume that when folks ask questions here they are primarily after information not perfect use of English.
Adrian K
i have tried to reword the question to make it clearer what i am looking for. The main reason for the down vote was it doesn't address my question, it is seemingly a generic answer. I will say i have read the link you sent and it shows exactly why i am confused, MS is really selling this thing as a cloud... it can do everything.... ;(
Nix
+1  A: 

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

Nix