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.
I think in a loosely coupled environment it is appropriate to architect for data redundancy. Within the boundaries of a strongly cohesive logical unit of work you allow for shared data and services, which is a for of tight coupling. Crossing these boundaries I think you should strive for independency and so loose coupling.
Loose coupling means independency. Loosely coupled components do not rely on each other. Not even on each others stored data. Each loosely coupled environment maintains its own copy of (a relevant subset of) the data and services. In loosely coupled environments redundancy must not be seen as poor design, but as strong design. Banning redundancy across "decoupling" borders makes the coupling more tightly. Maintaining redundancy across these borders makes the loose coupling more robust. EDA (event-driven architecture) is perfectly suited by its nature to support automatic data synchronization mechanisms in redundant environments while maintaining loose coupling.
http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html
http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1246430,00.html?track=NL-547&ad=581976&asrc=EM_NNL_1092473&uid=1
Jack
Excellent response, Jack. Thank you for contributing.
I think that ACID transactions between services should be discouraged.
In fact I’ve just bloged about it thes weekend:
http://www.ddj.com/blog/architectblog/archives/2007/04/transactions_be.html
and
http://blogs.microsoft.co.il/blogs/arnonrgo/archive/2007/04/16/12007.aspx
Forge the hard line.
I’m with you.
No ACID transactions across service boundaries.
No referential integrity between the databases of different services.
At the very least, I’d say have a separate logical db per service (given that it needs a db). If the service’s SLA is such that it doesn’t require dedicated hardware, you could house that logical db in the same dbms instance as other dbs. However, that’s a deployment detail.
Also, because of differing SLAs, you’d expect different backup strategies – probably based upon differing "time-to-restore" requirements.
In other words, we aren’t carving service independence into the database. The DB belongs to the service, period.
<i>"I think in a loosely coupled environment it is appropriate to architect for data redundancy. Within the boundaries of a strongly cohesive logical unit of work you allow for shared data and services, which is a for of tight coupling. Crossing these boundaries I think you should strive for independency and so loose coupling."</i>
Jack i couldn’t agree more.
Having said that the problem with the pattern that you outlined here is the fact that you still have to deal with lots of moving parts and figure out yourself how to build your system in a way that will conform to that pattern. As we know lots of things could get wrong since the entire process isn’t streamlined. Another problem is that the interaction between the tightly coupled services still need to go through the network to trigger events and to update the data base. That leads to a lot of unnecessary inefficiency and complexity of the runtime environment.
<a href="http://www.gigaspacesblog.com/2006/12/09/sbas-general-principles/">SBA – Space Based Architecture</a> is aimed to address those challenges and make this pattern significantly simpler to implement. The core element in SBA is the notion of Processing-Unit, processing units define the unit of scale and fail-over and contains all the tightly coupled services along with the data, the application logic and the event routing in a single self sufficient process! The load is balanced between the processing unit based on some sort of affinity-key (it could be customer-id, correlation-id, session-id depending on the application) . In away you can think of that affinity key as the key that defines the boundaries between the different unit and determine which part of the data will be handled by each unit. Saclability is achieved simply by adding those units. Since they are self sufficient you are gauranteed to achieve linear scalability.
In this way we simplify dramatically the pattern that you just described and make it very efficient since all the interaction between the tightly coupled services is done in-memory. In addition to that we reduced the amount of moving parts significantly.
There is a whitepaper that is published on the theserverisde and describes that model in details: <a href="http://researchlibrary.theserverside.net/detail/RES/1173198199_151.html"> The Scalability Revolution: From Dead End to Open Road
</a>. You can also find a code example based on that pattern <a href="http://www.gigaspaces.com/wiki/display/GS/SBA+-+Introduction+and+Example">here</a>
<i>"In other words, we aren’t carving service independence into the database. The DB belongs to the service, period."</i>
Udi i would even add to that the data that belong to the service can become part of the service process if were using In-Memory-Data-Grid.
You may want to look at the following presentation that was given at the QCon event: <a href="http://www.gigaspaces.com/download/SBA.pdf">Scalable as Google Simple as Spring</a>
Nati S.
<a href="http://www.gigaspaces.com">GigaSpaces
Write Once Scale Anywhere</a>
Fascinating, Nati. I will look into these.
— Nick
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.