Between Mid-80's and beginning 90's, when distributed databases and client/server applications began to become mainstream a great technology was introduced: two-phase commit. It basically meant that when a client (or middle tier) wanted to perform a data transaction (create, update, delete) over 2 or more separate databases, it was able to do this in a safe way: either the transation succeeded in all the involved back-end databases, or the complete transaction was rolled back. Various databases started to support this, using the (if I recall correctly) XA standard.
Now I find myself wondering what happened to that great transaction model.
In the current world that we call SOA and BPM technology, suddenly we talk about calling services, hoping everything goes well. And if not, well, there is Compensation. Which, by the way, might fail too. Ouch!
It's amazing - I've seen client/server development tools mature, until they provided a quite stable development and run-time environment, including transactions, debugging, etc.
Then, boom, came the webmodel, and we started all over, with buggy development, debugging ("println("I am at point X and variable Y has value:", y).
And now we have the BPM technology development and run-time environment, and I find myself once again missing all these things that used to be normal....
Anyone knows if there are BPM technology suites that support a two-phase commit like transaction model? Has any of those WS-* standards reinvented this yet? I hope so.
At least than we can think up a new technology to start all over again :-) Mobile?
1 comment:
Have a look at the Transaction Sub-Process and Compensating Activityconcepts in BPMN which asre designed to work alongside WS-Transaction style protocols.
Post a Comment