Patrick Logan:
I've written an essay on what I think the next database
architectures should look like. If you read through my blogs you'll
know it has something to do with tuple spaces and star
schemas.
I'm looking forward to it.
Apparently, Patrick took a peek at
WS-Transaction, didn't get any further than the author list and
decided it wasn't any good. I agree that two phase commit is
traditional... I hold out more hope for compensating transactions
via asynchronous messages.
In any case, on the higher level discussion, I think that there
is something more fundamental than propagation delays due to the
speed of light. At some point larger systems stop being
larger copies of smaller systems but become multi-cellular.
The cell boundaries are not merely for scale, but represent trust
boundaries. There are many reasons for this... privacy,
security, robustness, encapsulation, etc.
A distributed system across trust boundaries is where I believe
we are collectively heading. The internet shows us the
beginnings of what is possible... for the subset of things that are
generally always online and publically accessible. Expanding
this to mobile and access controlled is the next big thing.
I did read further than the list of authors. But nothing like a controversial statement to get people interested in a topic.
I do think the compensating approach is better than the atomic approach at the distributed business level of "transaction". But I am not sure either should be a part of the connection architecture.
Patrick, I am not clear by what you mean by "part of the connection architecture".
The point of WS-transaction is exactly what you appear to desire: Compensation "meta-data" if you will should be a part of the documents exchanged among business partners, no matter how those documents are exchanged.
My understanding is that WS-Transaction information goes in the SOAP header. My preference would be to make transaction information a part of the delivered document itself.
SOAP could be a transport to get the document to its destination. But some other mechanism could be the transport too.
Overall, I am concerned about SOAP and WS-xxx becoming some kind of conglomerate "distributed systems programming" notation. Much of this (orchestration, compensating transactions, business process definition) should be in the documents rather than in the headers of our currently popular transport mechanism.
I am thinking of business contracts that can evolve among partners, as opposed to a standard header format for some current industry notion of compensating transactions.
Yet clearly I see the analogy and have to run a few scenarios through the spec.