Jeremy D. Miller -- The Shade Tree Developer

"force all data access to be done through exchanging messages over a brand new ESB infrastructure"

Ah-hah! That'll solve it. Now, back to the bat cave, Robin.

I could almost hear the conversation in the room before that decision. "If only we could solve our anemic process. I know! We need (*cue superman music*) MORE TOOLS!"

Reminds me of the person who not only wanted data access to be done through services, but that all *joins* should be done by the C# code *after* it was pulled through the web service.

Gee, I wonder who the company might be....hmmm....

"Water under the bridge"?  I think you mean "water over the fall".

Yeah, it was pretty stunning (though also hilarious) to hear the idea.  You know, the prototype against tables with 10 rows didn't before that bad, so how bad could it get with a gigabit network (production tables with hundreds of thousands or millions of rows)?

Luckily, it didn't make it past the next prototype (feel sorry for the two days of the developer's life he'll never get back).

Had to look up the reference, but, yes.

>>> culminating for me the day that our chief architect tried to demand that all data access be done through web services

What's so wrong with that concept? I'm asking from the standpoint of total ignorance on my part, really.

For example, the ADO.NET Data Services (Microsoft's forthcoming RESTful framework for data access, Link here: http://astoria.mslivelabs.com/) is implemented upon the ADO.NET Entity Framework and the RESTful facilities in Windows Communication Foundation. It basically brings a stateless data access to the web with CRUD support, all done via HTTP. It also serializes either JSON or AtomPub.

For any given data source to qualify as "ADO.NET Data Services-ready" it must implement two interfaces: IQueryable and IUpdatable. One of the tenets of the ADO.NET Data Services Framework was to be "persistence ignorant", meaning it doesn't matter who provides the data. However, as of today it only works with SQL Server 2005. In the long term other DB vendors will implement IQueryable and IUpdatable too.

With ADO.NET Data Services the queries (very succinctly) are sent to the service over the wire, and the corresponding result sets are returned to the client. The heavylifting is carried out by the DB engine, as it has to be. In the cases where it's not possible to represent a query with a RESTful URI, you have to pull the raw data and do the heavy lifting via C# code in the client as one commenter pointed out.

I understand this technology is best suited for the WWW, however it also targets corporate development. In that regard the ADO.NET Data Service Framework already provides the respective client libraries.

Now my questions:

Isn't this story about "data access done through web services" ?

What's wrong with it? (boyond the somehow un-performant HTTP protocol and serialization overheads, which are evident).

Thanks.

@Fernando

I think the key problem is not that he decided to do SOME data access through web services, but ALL data access.  Right tool for the right job.

I use O/R Mappers.   Generally, they don't have the same performance problems that a web service might have.  They call databases without all the serialization.  But I still wouldn't say every project  or every query or ALL data access must be done through an ORM.  I use them where they're appropriate.  Thats what being a programmer (or architect although I hate that word) is all about.

I think "right tool for the job" sums it up nicely.  If you have millions of transactions or other heavy lifting going on between the database and whatever application, you really don't have the "convenience" or whatever one would call doing all data access through the web services.  I've seen it attempted with WCF and that didn't fly at all.  I've also seen it attempted back with WSE 3.x stuff.  Maybe in certain SOA situations it might work fairly good, but even then SOA != Web Services and Web Services != SOA.