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

+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). 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>

Received on Tuesday, 28 October 2003 12:03:50 UTC