RE: Definition of Choreography

David

I don't think we disagree. I, like you, agree that it is important to
standardize on how to sequence processes as this is very necessary for using
web services within an organization.

What I am trying to do is add consideration of the fact that internal
"private" business processes can be **constrained** because they have to
interact with other public processes that you cannot control. To do this
effectively, you need to have a way of specifying how to interact with the
public process and should be expressed as a choreography that describes the
messages.

David

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Saturday, October 19, 2002 3:59 PM
To: 'Burdett, David'; 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Definition of Choreography


David,

Your viewpoint is understood, guess we agree to disagree.  BEA believes we
should standardize on how to sequence processes.  That certainly appears to
be the largest area of innovation in this space.  We're certainly getting
lots of interest in customers for further and ongoing work on bpel4ws, like
big bank kind of customers that get our attention.

Cheers,
Dave



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Burdett, David
> Sent: Friday, October 18, 2002 4:58 PM
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: Definition of Choreography
>
>
>
> 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.
>
>

Received on Sunday, 20 October 2002 21:27:28 UTC