Is it really such a bad idea to use webservices to wrap data-access layer?

Question

I am not convinced - I think it might be useful to expose your data to different consumers that can build their front-end apps on top of your webservice.

Can someone provide samples of when using web-services to wrap data-access layer is a bad idea?

Answer 1

Well, if you are exposing your entire API over a web service with no security, that might be a bad idea.

But if you are exposing the required parts of it, in a secure, read-only way, and your customers like it, that must surely be a good thing.

If you ever need to persuade management remember that "Google do it."

Answer 2

Depending on what you define as a 'data access layer', there may or may not be a good reason to do it. Traditionally, distributed API's such as web services or RPC layers live on the next layer up. This has the following advantages:

1. Without the tight coupling to the DB You can tune this layer to play nicely with distributed access - for example organising the API to minimise round trips.

2. You can put an additional layer of validation on the API. A raw data access layer may permit bad data to be written to the system. For this reason, it would be bad to expose it to untrusted clients.

3. You can put application-level security over the services layer in a way that might not be possible to a data access layer.

4. Points 1 and 2 mean that you get re-use of the business rule validations in the middle-tier.

Exposing a simple API for CRUD operations can also be achieved by directly connecting to the database server, so a web service layer over the top of this is not going to give you anything that the DBMS doesn't already provide. Some DB engines can also directly serve queries over HTTP so you can tunnel it through most firewalls. However, the security aspects of this mean that you almost certainly don't want to expose this to the public internet.

While you could in theory expose CRUD operations (which is what I am assuming that you mean by 'data access layer') through a web service, there are some fairly good reasons not to do this and relatively little benefit to doing so.

Answer 3

The major push in today's world is towards cloud or SaaS computing.

With that in mind a lot of major applications including SalesForce (CRM), Google, Parature (helpdesk), etc expose their applications via web services.

It isn't just a good idea, it's the only way to have your application taken seriously by companies looking to integrate it into their environment.

That said, the only example I can think of when utilizing web services to wrap your DAL is bad idea is when only one application will call the DAL and it is under your direct development control. This is due to the performance penalty paid for serializing/deserializing the data across a web service boundary.

Answer 4

In .NET, WCF appears to offer a way around the performance hit that Chris mentions. WCF should allow you to to have your data access component run in-process for your own application, but also be readily exposed as a Web service. (Disclaimer: I haven't actually implemented this, just looked at it.)