Re: [ws-chor] 7/28/2003: Reqts 1.0 Comments

I for one, agree on both points.

I would much rather use the term 'flow' (for the choreography side of 
things) which depicts the fact that there are two possible responses 
following the request.

I'm not comfortable with the term 'control logic' because I don't think 
it's precise enough to distinguish choreography from execution. We are, 
after all, looking for good terms that convey the appropriate meaning, 
so a reader of the specification can easily tell which is which. I think 
as far as distinction between the two goes, we may disagree on the 
details or how much is too much, but we all agree on the core principles.

Perhaps, execution logic or computation logic would be a more accurate 
term to describe what a particular service does (e.g. using BPEL or 
Java). Or we can use the dreaded 'internal ...' :-)

arkin

Yaron Goland wrote:

>The key terms are 'machine processable' and 'control logic'.
>
>The directed graph describing the legal combinations of message sequences is
>something that clearly should be machine processable. My own scenarios
>require that the graph be machine processeable otherwise it would be
>impossible to fulfill requirements like being able to generate a language
>skeleton and being able to validate real time messaging behavior and its
>compliance to the graph's definition.
>
>Where I think the real confusion is coming is from the term 'control logic'.
>What I specifically mean is that when a web service has an option for which
>message it can send next then the logic the web service uses to choose must
>not be expressed in the choreography definition.
>
>To use one of our own examples a traveler sends a travel agent a request to
>book a trip. The choreography says that the travel agent can either respond
>immediate with 'trip booked' or they can respond with 'request received but
>booking info will be sent later.' The choreography would only specify that
>the travel agent has a choice of which message to send but will not provide
>any actual control logic that would specify how the choice is made.
>
>		Yaron
>
>  
>
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>[mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
>>Sent: Tuesday, July 29, 2003 6:37 PM
>>To: jdart@tibco.com
>>Cc: Monica Martin; Daniel_Austin@grainger.com; public-ws-chor@w3.org
>>Subject: Re: [ws-chor] 7/28/2003: Reqts 1.0 Comments
>>
>>
>>
>>Jon Dart wrote:
>>
>>    
>>
>>>More problematic is the proposal to use prose annotation to
>>>      
>>>
>>replace or
>>    
>>
>>>to abstract away some constructs. Specifically, the proposal to
>>>"remove control logic from the cDI .. the cDI programmers
>>>      
>>>
>>would have
>>    
>>
>>>to annotate the logic with human readable statements in order to
>>>explain their intent." (3.2.3.6). IMO this is not something
>>>      
>>>
>>on which
>>    
>>
>>>we have consensus (at least not yet). In fact I think it is
>>>      
>>>
>>possibly
>>    
>>
>>>in conflict with some of the other requirements, such as
>>>      
>>>
>>D-CR-035 and
>>    
>>
>>>D-CR-038.
>>>      
>>>
>>Agreed. If it really boils down to being a description
>>language that is
>>not machine processable, then can't we just use UML?
>>
>>arkin
>>
>>    
>>
>>>--Jon
>>>
>>>      
>>>
>>
>>
>>    
>>

Received on Monday, 18 August 2003 22:15:11 UTC