RE: question: relation between WS-CDL and WSCI

> is the job of the travel agents to discover the "credit check" service

> and adapt their choreographies to the "non-global model" 
> choreography of the "credit check" service

It seems to me that a BPEL abstract process might be a better model for
what you are trying to do in this case.

Ugo

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Titi Roman
> Sent: Friday, April 16, 2004 8:02 PM
> To: Nickolas Kavantzas
> Cc: WS-Choreography List
> Subject: Re: question: relation between WS-CDL and WSCI
> 
> 
> 
> Hi Nick,
> Thanks for your answer. See just some questions/comments 
> in-line that just crossed my mind.
> 
> ----- Original Message -----
> From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
> To: Titi Roman <dumitru.roman@deri.ie>
> Cc: Assaf Arkin <arkin@intalio.com>; WS-Choreography List 
> <public-ws-chor@w3.org>
> Sent: Thursday, April 15, 2004 8:14 PM
> Subject: Re: question: relation between WS-CDL and WSCI
> 
> >
> > See comments about WS-CDL below.
> >
> > --
> > Nick
> >
> > >
> > > As far as I understood and please correct me if I am wrong, WS-CDL
> supports
> > > only "global model"(i.e. the multi-participant view of the overall
> message
> > > exchange) - this sounds to me as a static linking between web 
> > > services.
> What
> > > about the dynamic linking between ws from the point of view if 
> > > coneversation?
> >
> > Why does the global model implies static linking? I am not sure I
> understand this.
> >
> > And what is the dynamic linking between ws from the point 
> of view of 
> > the coneversation? Can you elaborate on this more?
> 
> What I meant by this was that when you specify a choreography 
> all the participants are known a-priori (static linking). 
> What I miss is: I want to make a service accessible through 
> the internet and I want to describe in a language (hopefully 
> WS-CDL) how it behaves when someone uses it - note that I do 
> not need a "global model" to do this since I do not care who 
> will use it (e.g. a "credit check" service will offer its 
> service to potentially thousands of travel agents - it is not 
> the job of the "credit check" service to conform to the 
> thousands choreographies of the travel agents, but is the job 
> of the travel agents to discover the "credit check" service 
> and adapt their choreographies to the "non-global model" 
> choreography of the "credit check" service (i.e. dynamic 
> linking)) - is it possible to describe the way "credit check" 
> service behaves in my scenario in WS-CDL? if yes, I 
> personally find it very unintuitive in this, I suppose, very 
> realistic scenario(I understood from your mail that you and 
> Steve have a proposal related to this issue - is it possible 
> for me to have access to
> it?)
> As you can see my example is in the context of section 
> "3.1.1.3.2 Variation 2" of your current draft on requirements 
> - while it can be the case for the "credit check"  service 
> (new credit bureau) to "join" the travel agent choreography, 
> it can also be the case (and I personally believe that it is 
> very realistic) for the travel agent to join the "non-global 
> model" choreography of the "credit check" service(which I 
> tried to point out in the above example). Then why not just 
> add another requirement(e.g. "A sub-choreography must be 
> generated and integrated in the "global model" choreography 
> for each service discovered and used o the fly") and try to 
> tackle also this, I believe very natural problem, in the 
> choreography language?
> 
> Thanks a lot and I will surely read carefully the other 
> comments from you and Steve's last email and I'll come up 
> with new questions ;-). Titi Roman
> 
> >
> > > What about the view of the overall message exchange as 
> seen from one 
> > > participant? Isn't WS-CDL supposed to support also this view?
> > >
> >
> > I have filled an issue for this in the Cambridge F2F and myself and 
> > Steve
> have
> > an action item to present our proposal to the group.
> >
> 
> 
> 
>

Received on Friday, 16 April 2004 15:00:26 UTC