Re: Choreography and REST

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 13:35:15 UTC