The concept that web services are small items of functionality or data which are bundled up together and exemplified as small, stand-alone organizations is fairly obvious, and makes sense. But exactly how do services connect with databases they use or offer an interface for?

For instance, when moving from the monolithic, 2-tier architecture having a massive database that handled everything to some services-based architecture, how's the database affected? May be the database chunked into more compact databases and every one interfaced with using a service, or does each service simply communicate with the initial massive database?

Also, when the database get's put into, say, something for user authentication and something for product information, where would the numerous-to-many entity that monitored product sights per user within the original massive database finish up?

To put it simply, "it does not matter".

Do whichever you prefer.

In the Service API level, the DB "does not exist", and it is simply an implementation detail.

When the API is performed correctly, the implementation from the database shouldn't "seep through" the API layer towards the clients.

Once you have accomplished that in the API level, you are able to decide to leave the DB "out of the box" (whether it's functional, works, maintainable, etc.), or start breaking everything apart all at one time, or incrementally.

Clearly, smashing the DB up will have its very own challenges and issues.

So, I'd begin with the help as well as their APIs, and ensuring both you and your customers are pleased with individuals. That process alone may make your choice for you personally.

I believe Martin Fowler comes with an interesting undertake this very subject in the Database Thaw article (essential-read I'd say!):

Should you switch your integration protocol from SQL to HTTP, it now means you are able to change databases from being IntegrationDatabases to ApplicationDatabases. This transformation is profound. ... Should you integrate through HTTP it no more matters how an application stores its very own data, which consequently means a credit card applicatoin can select a data model which makes sense because of its own needs.

Therefore the switch "from DB to WS" would allow you to care much more about your data. You shouldn't have to first tailor everything to suit in to the relational model, but you could utilize other models too just like a key/value store, a graph database or perhaps a document oriented approach. - Whatever is the greatest fit for that domain at hands. It might obviously be a mix of different types oftentimes.

My undertake it's which will Hartung's response is almost perfect, but I'd range from the special situation of ETL (Extraction, Transform and Load).

This integration pattern may also be used poor WS's, and involves a WS call (sometimes routed or orchestrated by a company Service Bus (ESB)), to extract data from a DB.