RE: Choreography and REST

Christopher,

It seems to me that there are 2 distinct problems:
Problem#1: Describe the protocol of messages exchanged between 2
parties. Usually called Choreography. This is simply a interface
definition that needs to be language neutral and can be easily expressed
using XML. (WSCI is trying to address this problem).

Problem#2: Implement the workflows that are compliant with those
collaboration protocols. This is executable logic that "scripts" a set
of components into a long-lived transaction. Those language have built
in support for asynchrony, flow control, long-lived transactions etc..
And in this case, it is true that XML is a loosy and unintuitive
representation for writing executable code.

Both problems benefit from a visual representation that enables between
communication, training, etc...

Based on my understanding, the pattern suggested by Paul is trying to
address #1. It is also known as the "shared repository pattern".

It will be interesting to see how BPEL4WS tries to address those 2
problems.

Cheers,

Edwin


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Christopher B Ferris
> Sent: Friday, August 09, 2002 10:16 AM
> To: bhaugen
> Cc: [email protected]
> Subject: Re: Choreography and REST
> 
> 
> 
> 
> 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: [email protected]
> phone: +1 508 234 3624
> 
> 
>                                                               
>                                                                     
>                       bhaugen                                 
>                                                                     
>                       <linkage@interacc        To:       
> [email protected]                                            
>            
>                       ess.com>                 cc:            
>                                                                     
>                       Sent by:                 Subject:  Re: 
> Choreography and REST                                                
>                       www-ws-arch-reque                       
>                                                                     
>                       [email protected]                               
>                                                                     
>                                                               
>                                                                     
>                                                               
>                                                                     
>                       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
> 
> 
> 
> 
> 
> 
> 
> 
>