- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Fri, 9 Aug 2002 14:16:07 -0400
- To: bhaugen <linkage@interaccess.com>
- Cc: www-ws-arch@w3.org
Bob, I don't disagree. However, the pre/post condition semantics need to (somehow) be expressed. REST itself doesn't address this. Where would we find the declarative pre/post conditions expressed not only for a resource, but for a class of resources? for classes of related resources? What this ends up looking like is a distributed Makefile and how many people (especially business types!) can read, understand and internalize a Makefile? In my expefrience, very few. Personally, I like declarative languages, I think it is a superior approach. But, most people have a *really* hard time with them. XSLT is a good example. Most people I know throw their hands up in despair when faced with having to write, or worse debug, an XSLT stylesheet:) Cheers, Christopher Ferris Architect, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com phone: +1 508 234 3624 bhaugen <linkage@interacc To: www-ws-arch@w3.org ess.com> cc: Sent by: Subject: Re: Choreography and REST www-ws-arch-reque st@w3.org 08/09/2002 12:32 PM Christopher Ferris wrote: >Paul's analysis doesn't take into account the fact that > there are real business issues to be considered w/r/t > the order of things that need to be understood > *and agreed upon*, a priori to beginning an exchange > of messages. Chris, I agree with every word of your paragraph, but Paul's articles have caused me to rethink how I might satisfy the business requirements. As you know, I'm coming from the ebXML Business Process group where we put a lot of emphasis on choreography. But since then, as we got deeper into the problem (in UN/CEFACT eBTWG), it became more clear that choreography decisions are business decisions (or decisions of whatever is the domain of discourse) and not just programming logic e.g. forks and joins and state transitions. So we started to use business object states (from a semantic business model) as the basis for choreography expressed as pre and post conditions for document exchanges. Now I'm opening my mind up to the direction Paul Prescod is proposing and thinking that it fits a lot with where we went in eBTWG, if you think of the business objects as REST resources. Another way to think of it is as speech acts in a structured conversation. One speech act, a commitment, promises a delivery of goods or services; a reciprocal speech act promises payment. Subsequent speech acts notify of the delivery and payment events. Each speech act becomes a REST resource, which can then be used as a posting address or condition for subsequent speech acts. There can be published rules (other REST resources), and there is a kind of choreography embedded in the speech acts. But it's very different from the procedural workflow style of choreography. Think about it. I don't have it all worked out in my mind yet, and don't know if Paul has either, but don't dismiss it out of hand. (P.S. I don't know if my speech-act scenario is anything near what Paul has in mind.) -Bob Haugen
Received on Friday, 9 August 2002 14:20:15 UTC