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

Question

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 loosing 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.

Answer 1

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.

Answer 2

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

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

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

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

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

6. 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.

7. 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.

8. 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.

9. 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.

Answer 3

• Web Services form an API, defining the allowed interactions between external systems and the application's data.
• Web Services decouple the database from external interactions and enabling the data layer to be managed independently of those outside influences.
• Allowing access only by Web Services ensures that application logic gets the chance to execute, protecting data integrity.
• Web Services allow the most appropriate authentication/authorization measures to be taken, as opposed to a database requiring a username and password/table level privileges.
• Web Services provide an opportunity for automatic service discovery and configuration to be used.
• Web Services traffic can be encrypted for transit over unsecured networks. Don't know of any direct DB connection solutions that enable that...?

Most of these points go for any formal API, not specifically Web Services.