RE: Definition of Choreography

Ricky

You said ...

>Each state constraint what event can 
>happen (event can be what SOAP message to send or what SOAP message to 
>receive).  Each event defines the next state.  Effectively, we are defining

>what are the possible message exchange sequence without describing the 
>internal decision making process.

I completely agree ;)

David

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Friday, October 18, 2002 6:17 PM
To: Burdett, David; 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Definition of Choreography


Although WSCI and BPEL explicitly state that they has a part focusing in 
public protocol, I agree with David that they are actually focus in the 
private implementation.  Putting the conditions in the <if><then><else> 
certainly doesn't belongs to the public part of the process.  WSCI is 
basically BPML which tries to specify the private part of the execution 
flow.  BPEL believes that a public protocol is a subset of the private 
protocol so the same language model can be used to represent both.  I can't 
prove it right or wrong.  To me it is easier to define another model from 
scratch to focus in public protocol rather than looking at how to strip 
things out from a workflow model to support the public protocol.

Think about how we define network protocol (e.g. TCP, SMTP, HTTP ... etc.) 
using a finite state machine.  Can the public protocol be just an XML 
representation of a state machine.  Each state constraint what event can 
happen (event can be what SOAP message to send or what SOAP message to 
receive).  Each event defines the next state.  Effectively, we are defining 
what are the possible message exchange sequence without describing the 
internal decision making process.

Rgds, Ricky

At 04:58 PM 10/18/2002 -0700, Burdett, David wrote:

>Mike
>
>Some observations on WSCI, BPEL4WS and choreographies.
>
>Having reviewed WSCI and BPEL4WS, they both tend to focus on how to
sequence
>processes to carry out a particular activity. As such they tend to focus on
>"private" processes within the enterprise.
>
>What I don't think they do so well, is describe the public processes, often
>described as choreograhpies, that **constrain** what a private process can
>do when interacting with services outside of its direct control.
>
>I think this is an important distinction as:
>1. Public processes need to be standardized, private ones do not.
>2. Anything that needs to be standardized should have a formal way of being
>defined as an aid to understanding and therefore interoperability
>
>You also need to distinguish between the generic implementation of a
>standardized process/choreography and an individual actual implementation.
>
>A generic choreography definition just needs to say, for example, ... "if
>you send me an "order" then you must send me an "order response" back - and
>really nothing more".
>
>I could have said, but didn't ... "if you send me a RosettaNet Order
>contained as an PKCS7 encrypted attachment on a "SOAP with attachments"
>message to this URL using HTTP, then I will send you a RosettaNet Order
>Response in the same format to the URL you specify in return".
>
>It's all to do with layering. The generic choreography is a universal
>business pattern that is independent of how it is implemented, and
>specifically the service that implements it. If the only way you can define
>a choreography is as part of defining an actual instance then you will get
>unnecessary **massive** duplication of choreography definitions.
>
>David
>
>-----Original Message-----
>From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
>Sent: Friday, October 18, 2002 3:12 PM
>To: www-ws-arch@w3.org
>Subject: RE: Definition of Choreography
>
>
>
>
>
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@acm.org]
> > Sent: Friday, October 18, 2002 3:45 PM
> > To: Cutler, Roger (RogerCutler)
> > Cc: 'Dave Hollander'; Burdett, David; 'Mark Baker'; Champion, Mike;
> > www-ws-arch@w3.org
> > Subject: Re: Definition of Choreography
> >
> >
> > Another +1 from me.  Let's see some use cases that
> > demonstrate why it's important to expose choreographies.
> > Because as we've seen from these
> > specs, they're not exactly simple, and if you can accomplish something
> > without needing to agreeing to new stuff, that reduces coordination
> > costs (read; reduces cost of doing business).
>
>I really, really hope we can stay focussed on identifying the components,
>connectors, and data that are identified by the BPEL4WS and WSCI specs,
>determine which of these are important to cover in a Choregraphy spec, and
>write this up in a way that makes a good case to the W3C AC for chartering
a
>WG to define such a spec.  That's what we've agreed to do at the F2F and in
>response to the request for a tighter scope by the WS CG.  Use cases would
>definitely help in that effort, and I think the "Definition of
Choreography"
>thread has gotten some ideas going.
>
>A "devil's advocate" position that this isn't needed is very useful in
>sharpening our arguments, and Mark does SUCH a good job at it :-)  Still,
>let's not get too distracted by arguing for or against the idea that a
>Choreography spec is needed -- we already decided that it is! -- and focus
>on defining what exactly the scope of a Choreography WG would be.  When we
>have a better handle on that, getting pushback helps us make the case, and
>gets the counter-arguments on the record for the AC's use.
>
>To put it another way, I'll feel that we've done our job if we analyze WSCI
>and BPEL from the WSA framework, make the best case for a new WG, but the
AC
>disagrees.  I will NOT feel that we've done our job if we spend the next
>month arguing about whether to do the analysis or not and then offer
nothing
>to help the AC make their decision.