Re: Exchange type issue

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 18:53:10 UTC