How do web services and databases relate to each other?

Question

The idea that web services are small bits of functionality or data that are bundled together and encapsulated as small, stand-alone entities is pretty clear, and makes good sense. But how do services relate to databases that they use or provide an interface for?

For example, when moving from a monolithic, 2-tier architecture with a massive database that handled everything to a services-based architecture, how is the database affected? Is the database chunked into smaller databases and each one interfaced with via a service, or does each service simply interact with the original massive database?

Also, if the database get's split up into, say, a service for user authentication and one for product information, where would the many-to-many entity that tracked product views per user in the original massive database end up?

Answer 1

Simply put, "it doesn't matter".

Do whichever suits you.

At the Service API level, the DB "doesn't exist", and it's simply an implementation detail.

If the API is done properly, the implementation of the database should not "seep through" the API layer to the clients.

Once you've accomplished that at the API level, you can choose to leave the DB "as is" (if it's functional, performs, maintainable, etc.), or you can start breaking it all apart all at once, or incrementally.

Obviously, breaking the DB up is going to have its own challenges and issues.

So, I'd start with the services and their APIs, and making sure you and your clients are happy with those. That process alone may make your decision for you.

Answer 2

My take on it is that Will Hartung's answer is almost perfect, but I'd include the special case of ETL (Extraction, Transform and Load).

This integration pattern is sometimes used in the context of WS's, and involves a WS call (sometimes routed or orchestrated by an Enterprise Service Bus (ESB)), to extract data directly from a DB.

Answer 3

I think Martin Fowler has an interesting take on this very subject in his Database Thaw article (a must-read I would say!):

If you switch your integration protocol from SQL to HTTP, it now means you can change databases from being IntegrationDatabases to ApplicationDatabases. This change is profound. ... If you integrate through HTTP it no longer matters how an application stores its own data, which in turn means an application can choose a data model that makes sense for its own needs.

So the switch "from DB to WS" would let you care more about your data. There's no need to first tailor everything to fit into the relational model, but you could use other models as well like a key/value store, a graph database or a document oriented approach. - Whatever is the best fit for the domain at hand. It could of course be a combination of different models in many cases.