W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2006

Re: Exchange type issue

From: Charlton Barreto <charlton_b@mac.com>
Date: Sat, 04 Nov 2006 08:43:02 -0800
To: Steve Ross-Talbot <steve@pi4tech.com>
Cc: "Monica J. Martin" <Monica.Martin@Sun.COM>, Martin Chapman <martin.chapman@oracle.com>, "'Gary Brown'" <gary@pi4tech.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
Message-ID: <DDEC00B2-010E-1000-A257-BA3F9984731F-Webmail-10009@mac.com>

+10. Well said, Steve.

I prefer Gary's notion if explicitly representing a distinction between a choreo representing a request/response and a notification, since this clearly represents the MEP (in a generic sense, and not only what WSDL has defined) that is being described. Everything that I have seen in CDL does not serve to limit what it can describe. Whether Web Services stacks decide to implement notification or not is beside the point, since a) there exist SOAP 1.2 implementations which explicitly support notification, b) there are plenty of non-Web Services implementations which require the support of notification, and c) CDL needs to be able to accommodate more that what Web Services or even other protocols have envisaged at present. 

Having a new action type will greatly simplify endpoint generation and make explicit to higher level consumers of CDL (a human reading it or a modelling tool representing an abstraction of it) whether a response is coupled to a request or not. Thus, I support Gary's proposal for having a new action type, as I too feel that it is the best approach to deal with this. 

-Charlton.
 
On Friday, November 03, 2006, at 10:42PM, "Steve Ross-Talbot" <steve@pi4tech.com> wrote:
>I think the BPEL thing is a red herring. We have always been able to  
>model or describe more than BPEL can handle. Our concept of channel  
>identity is not supported by BPEL (from memory) and is much richer  
>than BPEL.
>
>The ability to have a response with not matching request is in-built  
>into WS-CDL and always has been. What we match is not request/ 
>response but send/receive - and interaction. A request and a response  
>can be modeled as two explicit interactions but can, as a  
>convenience, be modeled in a single interaction. If we have them  
>explicit then implementors can choose how to match (usually on  
>operation name) but I do not think this is mandatory. When we have a  
>request and a response in a single interaction the operation names  
>are by definition matched - they share the same operation name.
>
>A notification exchange type makes explicit a pattern which in turn  
>provides clarity of description. It becomes clear as to the intent.  
>And this can only be a good thing. Just because BPEL doesn't support  
>it doesn't mean we should not. Just because many Web Service stacks  
>do not support it does not mean we should not. One day they may well  
>support it and so by supporting what is in the standards and what the  
>wider non-web service community use ensures we achieve one of our  
>goals, namely that we all want WS-CDL to have wider utility than  
>current tools provide today and wider utility outside of a strictly  
>web service environment - hence the optional role interface in WS-CDL.
>
>Cheers
>
>Steve T
>
>On 3 Nov 2006, at 18:52, Charlton Barreto wrote:
>
>>
>> Hi Monica,
>>
>> I recall that we had these discussions regarding specific MEPs that  
>> are explicitly supported w.r.t. interactions (in general, any CDL  
>> implementation MUST parse in-out, in-only and robust in-only style  
>> interactions.), but not necessarily w.r.t. what a choreography  
>> could describe.
>>
>> As for WS-BPEL, I see this as an implementation detail, not  
>> something that should restrict CDL's capabilities. Either  
>> validation can be performed for endpoint generation, or an  
>> implementation emulate this in WS-BPEL endpoint generation, for  
>> instance, by modelling the decoupled request and response not as a  
>> single process but as two separate (non-composed) processes (WS- 
>> BPEL must be able to describe in-only as well as in-out, so the  
>> first process would be an in-only and the second an in-out, thereby  
>> decoupling the ultimate response from the inital request). There  
>> are a number of ways this problem can be approached in WS-BPEL, so  
>> we should not base what MEPs a choreo can describe on what MEPs  
>> BPEL can describe.
>>
>> -Charlton.
>>
>> On Friday, November 03, 2006, at 05:03PM, "Monica J. Martin"  
>> <Monica.Martin@Sun.COM> wrote:
>>>
>>>> Charlton Barreto wrote: Should it be illegal? While we agreed in  
>>>> issue X that a choreography should only "officially" support the  
>>>> use of in-only, in-out and robust in-only MEPs from WSDL 2.0,  
>>>> there's nothing as far as I can see in the spec that indicates  
>>>> that a choreography could not describe any of the WSDL 2.0 MEPs.  
>>>> This implies that we could support responses that wouldn't be  
>>>> matched to a request. If we have but one response in the choreo,  
>>>> and that is not matched to the initiating request, we in effect  
>>>> described an out-only with that choreo.
>>>>
>>>> I agree with Gary that 'notify' is a suitable value for that  
>>>> exchange action type, because in this case we are describing a  
>>>> 'notification'/out-only MEP with the choreo.
>>>>
>>>> -Charlton.
>>>>
>>>>
>>>>
>>>>> On Friday, November 03, 2006, at 02:34PM, "Martin Chapman"  
>>>>> <martin.chapman@oracle.com> wrote: In 1), why would we ever  
>>>>> allow a response that has not had a preceeding request? This  
>>>>> should be illegal! The only chellange is being
>>>>> able to match a response with a request. We could also allow  
>>>>> fancy patterns such as one request and mutiple responses (of  
>>>>> same or different type) without introducing this "notify" flag.
>>>>>
>>>>> Martin.
>>>>>
>>>>>
>>> mm1: This relates to previous discussions we had a conscious  
>>> decisions
>>> about the explicit MEP supported. One comment related to this to
>>> consider is that WS-BPEL specifically prohibits the use of this  
>>> pattern
>>> and any definition that includes it is rejected in static  
>>> analysis. This
>>> may create an incompatibility in endpoint generation if WS-BPEL is  
>>> the
>>> target. Thanks.
>>>
>>>
>>>
>>
>>
>>
>
>
>
Received on Saturday, 4 November 2006 16:43:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:47 GMT