Re: Exchange type issue

There is no such thing as an interaction in current web service  
standards nor a channel. But we have defined them in WS-CDL.
My point is to make things clearer at a business level rather than  
pin people to what is provided today. After all WS-CDL lives
at a higher level and so we have the opportunity to make things  
easier and clearer for descriptive purposes without making a rod
for the backs of implementors or stymying the ability of architects  
or designers to describe what they need to describe.

One could always refuse, as a matter of policy, to use notify  -  
perhaps because the current vendor stack does not support it.
Equally one could use it because one is not using Web Services as the  
principle stack.

At least this way we meet our aim of greater utility.

Cheers

Steve T

On 5 Dec 2006, at 15:54, Abbie Barbir wrote:

> Hi,
>
> I agree again with Martin, specifically, there is either a one-way
> message request, or a request-response.
>
> Abbie
>
>
>
>
> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Martin Chapman
> Sent: Tuesday, December 05, 2006 10:47 AM
> To: 'Gary Brown'
> Cc: 'Steve Ross-Talbot'; 'Charlton Barreto'; 'WS-Choreography List'
> Subject: RE: Exchange type issue
>
>
> My main technical argument is that there is no such thing as a notify:
> there is either a one-way message request, or a request-response; this
> is current, and as I see near future, web services technology.
>
> Martin
>
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org
>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
>> Sent: Tuesday, December 05, 2006 3:29 PM
>> To: Martin Chapman
>> Cc: 'Steve Ross-Talbot'; 'Charlton Barreto'; 'WS-Choreography List'
>> Subject: Re: Exchange type issue
>>
>>
>>
>> Hi Martin,
>>
>> When should WS-CDL be limited by what is well supported in Web  
>> Service
>> technology today? This would imply that when it is well supported,
>> there is going to be a time period where web services can execute it,
>> but CDL cannot describe it. Why does it have to be that way around?
>>
>> Would it not be better to ensure the CDL language is as expressive as
>> possible, and then enable tools to apply suitable restrictions or
>> warnings based on the capabilities of the technology they are  
>> deploying
>
>> to? As I have mentioned a number of times, CDL is applicable  
>> outside of
>
>> the Web Service arena, where notifications are not only supported but
>> common place.
>>
>> Regards
>> Gary
>>
>>
>> Martin Chapman wrote:
>>> I'm very much opposed to this, as notify is just a
>> bastardization of a
>>> one-way request. It is also not well thouht out or supported
>> in current Web Service technology, so why should this version of  
>> WS-CDL
>
>> account for it?
>>>
>>> Martin.
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-ws-chor-request@w3.org
>>>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Steve
>> Ross-Talbot
>>>> Sent: Tuesday, December 05, 2006 9:49 AM
>>>> To: Gary Brown
>>>> Cc: Charlton Barreto; 'WS-Choreography List'
>>>> Subject: Re: Exchange type issue
>>>>
>>>>
>>>>
>>>> I must admit I am still mystified as to the objection. As a
>>>> description language being clear about the intent seems a
>> good thing
>>>> and so adding "notify" or "notification" to the description in an
>>>> exchange adds clarity. How one chooses to implement said
>>>> "notification" or "notify" is entirely up to the implementor(s) of
>>>> the end point(s). It turns out many protocols have the
>> concept of a
>>>> notification as distinct from a respond and benefit from the
>>>> distinction. Given that it does nothing to the semantics of WS-CDL
>>>> but does enable a response to be distinguished in some way
>> is it not
>>>> a good thing as opposed to a bad thing?
>>>>
>>>> I guess we shall talk more on the call tonight/today.
>>>>
>>>> Cheers
>>>>
>>>> Steve T
>>>>
>>>> On 5 Dec 2006, at 09:32, Gary Brown wrote:
>>>>
>>>>
>>>>> Hi
>>>>>
>>>>> Personally I don't see this as being any different to having an
>>>>> action called 'notify'. The term still being used is related to
>>>>> notification - which is what I thought the objection was about.
>>>>>
>>>>> Although the suggested approach could be taken, my issue
>> is that it
>>>>> is adding a new flag that is only relevant when action="respond",
>>>>> and represents a state that is distinct from both a normal
>>>>> action="request" and action="respond" - therefore I see it
>> as being
>>>>> a redundant additional flag, where a new 'action' state could
>>>>> easily be used instead.
>>>>>
>>>>> However, if this proposal does overcome previous
>> objections, then I
>>>>> will support it.
>>>>>
>>>>> Regards
>>>>> Gary
>>>>>
>>>>>
>>>>> Charlton Barreto wrote:
>>>>>
>>>>>> In considering this, it is clear that we need the ability to
>>>>>> distinguish whether an respond is associated with a particular
>>>>>> request. However, there seems to be some difficulty with
>>>>>> introducing a new action="notify" to do this.
>>>>>> As such, would it be acceptible to everyone to instead use an
>>>>>> additional attribute for action="respond"? I don't see
>> that adding
>>>>>> an attribute is semantically any different from adding a new
>>>>>> action. However, it may be more amenable to those who
>> would prefer
>>>>>> not to express "in-out"/"notification" as a distinct action.  If
>>>>>> this direction is desired we could then have an attribute,
>>>>>> notification="true", used/parsed only when
>> action="respond", that
>>>>>> would indicate that the response is not associated with a  
>>>>>> request.
>>>>>> On Wednesday, November 01, 2006, at 09:09AM, "Gary Brown"
>>>>>> <gary@pi4tech.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> As discussed on the conf call last night, I will outline the
>>>>>>> requirements for this change and the benefits if can offer.
>>>>>>>
>>>>>>> 1) We need the ability to distinguish whether or not an exchange
>>>>>>> with action="respond" is coupled with a preceding exchange with
>>>>>>> action="request".
>>>>>>>
>>>>>>> A simple scenario would be where an interaction, with a request
>>>>>>> exchange, is followed by a choice that has two paths, and each
>>>>>>> path has an interaction with a 'respond' exchange for a normal
>>>>>>> response. Currently it is not possible to determine whether one
>>>>>>> of these is intended to be a response coupled with the request,
>>>>>>> or whether both are 'out only' messages, or whether the
>> user has
>>>>>>> in fact made an error in the choreography design, and is
>>>>>>> expecting both to be responses to the request.
>>>>>>>
>>>>>>> 2) The benefits of having a clear and explicit understanding of
>>>>>>> whether a response is actually coupled to a preceding
>> request are:
>>>>>>>
>>>>>>> a) Static validation - we can determine when a user has made an
>>>>>>> error, by specifying two normal responses.
>>>>>>>
>>>>>>> b) Deriving correct service interfaces - service
>> interfaces can be
>>>>>>> derived from the choreography description. However at the  
>>>>>>> moment,
>
>>>>>>> even a simple case where there is a request
>> followed by a
>>>>>>> separate interaction including a respond exchange, it may be
>>>>>>> unclear whether they are a one-way request followed by an 'out-
>>>>>>> only', or whether they are a request-response pair. Making this
>>>>>>> explicit in the choreography means that these ambiguities would
>>>>>>> not arise.
>>>>>>>
>>>>>>>
>>>>>>> In relation to the terminology question, after further thought I
>>>>>>> believe that 'notify' is actually a suitable value for the new
>>>>>>> exchange action type. This is because it is exactly that, an
>>>>>>> action. The term notify simply means that someone will be
>>>>>>> informed, it does not imply whether there is one or more
>> parties
>>>>>>> being informed. This is determined by the communication
>> structure
>>>>>>> on which that notification is being sent - and at present CDL
>>>>>>> only supports point to point.
>>>>>>>
>>>>>>> Regards
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>

Received on Tuesday, 5 December 2006 16:03:48 UTC