Why should a developer use web services instead of direct connections to a db? [closed]

I'm looking for a "top ten" list of reasons why we should be connecting to remote databases via web service instead of directly connecting to the db. This is an internal debate right now and I'm pro-web service but losing the argument. I have a basic grasp of WCF / web services, no one else does. We can do whatever we want moving forward but we need to stick with whatever we choose now.

Here is what I've come up with. Any more?

1. WCF web services can, if configured correctly, be more secure.
2. Changes to the DB only need to be made at the service level (config file or recompile service).
3. Once setup and hosted, web services are easier to consume.

Solution 1:

1. Security. You're not granting DB access to anyone but web server/app user.

   This is extra important when you have tons of users. You avoid the pain of user/role maintenance on DB side.

2. DB load reduction. Web service can cache the data it retrieved from DB.

3. Database connection pooling (hat/tip @Dogs).

   A web service can use a small pool of permanently opened DB connections. The helps in a variety of ways:

   • DB connection pool is limited on database server side.

   • opening a new DB connection is VERY costly (especially to database server).

4. Ability for fault tolerance - the service can switch between primary/DR data sources without having details of fail-over be implemented by service consumers.

5. Scalability - the service can spread requests between several parallel data sources without having details of the resource picking be implemented by service consumers.

6. Encapsulation. You can change underlying DB implementation without impacting service users.

7. Data enrichment (this includes anything from client customization to localization to internalization). Basically any of these might be useful but any of them is a major load on database and often very hard to implement inside a DB.

8. May or may not apply to you - certain architecture decisions are not DB acces friendly. E.g. Java Servers running on Unix have an easy access to a database, whereas a java client running on a Windows PC is not database aware nor do you possibly want it to be.

9. Portability. Your clients may not all be on the same platform/architecture/language. Re-creating a good data access layer in each one of those is harder (since it must take into account such issues as above-mentioned failovers/etc...) than building a consumer layer for a web service.

10. Performance tuning. Assuming the alternative is clients running their own queries (and not pre-canned stored procedures), you can be 100% sure that they will start using less than optimal queries. Also, if the web service bounds the set of allowable queries, it can help with your database tuning significantly. I must add that this logic is equally applicable to stored procedures, not unique to web services.

A good list can also be found on this page: 'Encapsulating Database Access: An Agile "Best" Practice'

Just to be crystal clear - some of these issues may not be applicable to ALL situations. Some people don't care about portability. Some people don't need to worry about DB security. Some people don't need to worry about DB scalability.

Solution 2:

In my opinion, you should not automatically be exposing your database as a web service. If it turns out you need a service to expose your data, then write one, but not all database access should be done through web services.

1. There is no reason why a database connection should not be secure
2. You can encapsulate the database in a data access layer (possibly Entity Framework)
3. Web services are no easier to consume than a well-written data access layer.