It’s just data

Future of data

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.

Posted by Patrick Logan at

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.

Posted by Sam Ruby at

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.

Posted by Patrick Logan at

SOAP headers are in the document.


    <title>Title goes here</title>
    <p>Body goes here</p>

Question: where does the document begin and end in the above XHTML?

Posted by Sam Ruby at

Hmm. OK.

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.


Posted by Patrick Logan at

I think that it could be a good idea to check out this blog post for some tips on how to write essay on halloween. Good luck

Posted by Lisa Abrams at

Add your comment