Wednesday, December 04, 2002

Web Services will provoke the return of rich UI clients Hacking Sherlock. ... Everybody in the room loved it, so we're doing a Sherlock plug in to show off how rich UIs can be used and are better than HTML user interfaces for some tasks. ... [James Duncan Davidson] It is also my intuition that web services will provoke the return of rich UI clients. Wether these be created using Mozilla/XUL/js, C#, java Swing or iBM's java JWF. But it seems like all developers I meet here in France don't believe in this prediction. Hopefully this blog entry will still be there in a few years, and I'll probably read it from something else than a web browser :-)   7:01:57 PM    comment []

An Interview with Tim O'Reilly An Interview with Tim O'Reilly. If you've talked to Tim O'Reilly, or heard him speak, you know that he's a man who likes to kick back and riff on his current favorite technical topics. From iPod to Web services to O'Reilly's upcoming Emerging Technology Conference, here's what Tim's thinking about these days. [O'Reilly Network Articles] Nothing new but a synthesis of ideas he already published or blogged. Reading Tim's thoughts is always a pleasure anyway. 6:52:09 PM    comment []

Multi-Party Business Transactions - UNCEFACT White Papers: multiple parties interacting in pairs is a good design pattern Multi-Party Business Transactions - UNCEFACT White Papers. Multi-Party Business Transactions - UNCEFACT White Papers - multiple parties were involved in the whole scenario, but they interacted in pairs and all coordination between dependent commitments was the internal and private responsibility of only one party. The paper lists several reasons why many parties will want to separate into pairs: * Simplicity - two is much simpler to handle than more-than-two. * Accountability - business contracts may involve many parties, but well-formed contracts always specify exactly who has agreed to do exactly what for exactly whom (i.e., only two parties to each contractual commitment). * The more parties to a contract, the more parties have to agree on everything. (And agreements about transaction rules are contracts.) * Economic commitments and events involve two and only two parties. * Security - need-to-know. Trading partners need to know about each other, but they rarely need to know what other partners each may have, and in many cases should not know even that others exist. * Decoupling to avoid ripples of change - if parties A and B change their procedures, it may not affect parties C and D, unless all four parties are bound into the same contract. For more fun, read the paper. Collaxa's Take:+1. This design pattern also known as a star interaction pattern is very important for building "self healing" and adaptable distributed applications: managing exception is easier in a pair conversations. The same is true for version control. [Collaxa's Take] 3:13:02 PM    comment []