C.A. Hoare's classic text Communicating Sequential Processes is now available online in PDF format.
Featured Post
These days, I mostly post my tech musings on Linkedin. https://www.linkedin.com/in/seanmcgrath/
Friday, May 07, 2004
Transactions and SOA
In our conceptualisation of SOA (asynch. business document messaging + REST) there is no temporal coupling between communicants, no resource locking and no stateful services. That pretty much rules out ACID based transactions:-)
Invariably, we get asked to explain our approach to transactions. Our answer is:
(a) if you really, really need transactions - don't attempt to do it with Web Services. The CORBAs and the TPMs of this work do that stuff bettter than any amout of new fangled lets-do-it-with-angle-brackets ever will.
(b) Do you really need transactions? There are times when yes, you absolutely do but equally there are times when you ended up needing transactions become of a function centric/object centric design model. Given that distributed transactions are hard and expensive (you cannot design away the network, you can hide it with dollar bills but you cannot design it away), it makes business sense to only use them when you need to.
(c) Automatic rollback? Give me a break. 99% of business process rollback is business logic specific and is most cost effectively done by people who understand the context and can compensate much more intelligently than machines. If you have really simple compensation requirements then congratulations! You are in a minority in my experience.
(d) Systems that have ACID semantics make perfectly good services to expose on an SOA. Like any paradigm, one of the skills of service decomposition is knowing when to stop. A temporal coupling boundary (such as a classic ACID) is a good place to stop.
I recommend Carlos Peres
why pessimistic transactions arent practical.
Invariably, we get asked to explain our approach to transactions. Our answer is:
(a) if you really, really need transactions - don't attempt to do it with Web Services. The CORBAs and the TPMs of this work do that stuff bettter than any amout of new fangled lets-do-it-with-angle-brackets ever will.
(b) Do you really need transactions? There are times when yes, you absolutely do but equally there are times when you ended up needing transactions become of a function centric/object centric design model. Given that distributed transactions are hard and expensive (you cannot design away the network, you can hide it with dollar bills but you cannot design it away), it makes business sense to only use them when you need to.
(c) Automatic rollback? Give me a break. 99% of business process rollback is business logic specific and is most cost effectively done by people who understand the context and can compensate much more intelligently than machines. If you have really simple compensation requirements then congratulations! You are in a minority in my experience.
(d) Systems that have ACID semantics make perfectly good services to expose on an SOA. Like any paradigm, one of the skills of service decomposition is knowing when to stop. A temporal coupling boundary (such as a classic ACID) is a good place to stop.
I recommend Carlos Peres
why pessimistic transactions arent practical.
Wednesday, May 05, 2004
Monday, May 03, 2004
Knoppix for peace of mind
I created a knoppix CD and booted my laptop with it. Wonderful stuff. GUI just worked. It sensed my external keyboard and mouse which just worked. It spotted my various USB-hosted disks which were mounted and just worked...
There is something deeply soothing about being able to boot from CD into a pretty fully fledged OS and look at all your files on all your partitions hosting all your OS's. When all else fails, there is always dd :-)
There is something deeply soothing about being able to boot from CD into a pretty fully fledged OS and look at all your files on all your partitions hosting all your OS's. When all else fails, there is always dd :-)
Subscribe to:
Posts (Atom)