SOA Question: should we carve service independence into the database?
One question we will be looking at is a fairly key one: as we build our Service Oriented Business App, and therefore drive the creation of services, we will be taking our nice, app-specific, logical data model and breaking it up to show which parts are in support of which services.
Do we then break those parts up into different actual databases? Alternative: we could simply create different sets of tables within the same db (a practice that the dev team is already familiar with).
Let's look at both sides.
- If the services are truly independent, they may need to scale seperately. They may need to move to other locations. They may need to change structure independently. All good reasons to seperate.
- On the other hand, if I have two databses, and make backups of them at 3:02am and 3:04 am, and the server hard drive goes down at 10am, prompting a restore, do I risk creating an inconsistent database situation because of the two-minute gap? Do I add complexity in database operations by creating the hard line between my service databases?
Important:
- If the services are designed well, there should be no cause for a single transaction that adds data under two different services.
- There should not need to be direct referential integrity between any two independent service databases.
I'm leaning towards forging a hard line. I'd like to know what you think.
Comments
Anonymous
April 16, 2007
The comment has been removedAnonymous
April 16, 2007
Excellent response, Jack. Thank you for contributing.Anonymous
April 16, 2007
The comment has been removedAnonymous
April 16, 2007
The comment has been removedAnonymous
April 16, 2007
The comment has been removedAnonymous
April 17, 2007
Fascinating, Nati. I will look into these. --- NickAnonymous
April 17, 2007
Nick Just a side comment, it would be great if you could add a preview button to your blog editor. I see now that the links that i posted didn't came out well.