Re: Web Services Choreography Description Language (WS-CDL) proposal

See my comments below:

Yaron Goland wrote:

> +1
>
> > -----Original Message-----
> > From: public-ws-chor-request@w3.org
> > [mailto:public-ws-chor-request@w3.org]On Behalf Of Steve Ross-Talbot
> > Sent: Monday, October 13, 2003 6:42 AM
> > To: Nickolas Kavantzas
> > Cc: public-ws-chor@w3.org
> > Subject: Re: Web Services Choreography Description Language (WS-CDL)
> > proposal
> >
> >
> >
> > Nick,
> >
> > here are the comments that I have already sent to you wrt to Oracle
> > contribution.
> >
> > I now share them as a matter of record.
> >
> > My main issue with the spec is that it involves active
> > participation in
> > the choreography between participants, which means that legacy
> > webservices are not going to be able to be included, which
> > will limit
> > the take up.
> >
> > It also does not 'extend' or build upon existing web service
> > interactions (i.e. message exchanges).

NK:
The language is abstract enough to be used without WSDL (and in this case there are no MEPs defined)
but additionally it includes a concrete binding (WSDL). In this case a WS-CDL interaction builds atop
of a one-way/request-response MEP pattern as defined by WSDL.

> Instead it defines the
> > concept
> > of shared state between participants, which needs to be synchronized
> > before associated interactions can be triggered. This is very
> > ECA like,
> > as opposed to passive monitoring of workflow.
> >

NK:
In WS-CDL, interactions are enabled immediately when a reaction guard is not defined.

When a reaction guard is defined, an interaction is enabled when the state referenced
on the guard is/becomes available. Since state resides at a role, an interaction can fire
even when a reaction guard references a state that is not synchronized between participants.
This is necessary in order to support the use-case of a buyer-seller-shipper engaging in a common
business transaction. State within a shipper will not necessarily be synchronized with the state within the seller initialy but
still a guard may need to be defined before an interaction from the seller to the shipper is enabled.

Additionally, WS-CDL allows a reaction to define a guard that requires state to be synchronized
between two participants before enabling the reaction's enclosed activities.

>
> > I don't think state information should be visible outside the web
> > service, other than the information provided as part of a message
> > exchange. My preferred choreography notation would simply define a
> > workflow coordination of high level message types, which
> > reference the
> > actual message types in the WSDL interfaces. Also, I think it
> > would be
> > better to approach the problem by defining a collection of
> > short lived
> > stateful choreographies, that when they are each performed,
> > obtain the
> > relevant business context as part of their initial
> > interactions (e.g.
> > first request should provide a reference/customer id, etc. -
> > which is
> > the same model as most human and electronic interactions in today's
> > business/web). This can also be mapped on to the more short lived
> > connection oriented approach.

The state information that is visible outside of a participant (Web Service, ...) is declared
in WS-CDL as observable state and it does actually capture the information exchanged between participants.

Additionally, internal state information of a participant (that does not really capture information that is exchanged
between participants) can be also declared and used in WS-CDL.

>
> >
> > I think the language should be in support of a passive
> > approach, acting
> > as a definition of an agreed collaboration, which can then be
> > used to
> > (1) help construct the individual (decoupled) participant web
> > services,
> > based on the observable behaviour they must exhibit, and then
> > (2) used
> > by each participant to verify that they (and their partners) are
> > correctly implementing the choreography.
> >

+1.

>
> > A central mechanism for policing the choreography is not required if
> > each participant (that is interested in obeying the choreography
> > definition) has the necessary checks defined in their local
> > implementations - which can be aided by the use of tools that
> > understand the external observable behaviour that is required.
> >

I completely agree.

Requiring a central controller for managing the choreography progress
is definitely not very practical in a distributed, peer-to-peer environment.


>
> > Cheers
> >
> > Steve T
> >
> > On Thursday, September 11, 2003, at 12:08  am, Nickolas
> > Kavantzas wrote:
> >
> > >
> > > Oracle would like to submit a document for consideration by
> > the W3C
> > > Choreography Working Group.
> > >
> > > This is being provided under the normal W3C IPR rules.
> > >
> > > The document can be found at:
> > > http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0018/
> > > wscdl_v1.zip
> > >
> > > We would like to request time on next's week F2F agenda for
> > presenting
> > > an overview of this submission.
> > >
> > > --
> > > Regards,
> > >
> > > Nick and Jeff
> > >
> > >
> > > This email is confidential and may be protected by legal
> > privilege. If
> > > you are not the intended recipient,  please do not copy or
> > disclose
> > > its content but  delete the email and contact the sender
> > immediately.
> > > Whilst we run antivirus software on all internet emails we are not
> > > liable for any loss or damage. The recipient is advised to
> > run their
> > > own antivirus software.
> > >
> >
> > This email is confidential and may be protected by legal
> > privilege. If you are not the intended recipient,  please do
> > not copy or disclose its content but  delete the email and
> > contact the sender immediately. Whilst we run antivirus
> > software on all internet emails we are not liable for any
> > loss or damage. The recipient is advised to run their own
> > antivirus software.
> >
> >