Re: Exchange type issue

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 Friday, 3 November 2006 22:42:13 UTC