OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Action Items for undefined behavior



> ford: Diane suggested I post this to the mailing list but after the 
> spec editing team call it was decided to open an issue to track all of 
> the undefined behavior in a single issue so as to give people enough 
> time to review and comment.

mm1: We just closed Issue #144 because the TC decided not to track all 
undefined behaviors in a combined issue, but handle them on a case by 
case basis as individual issues. Are we revisiting that decision? [1]

Reference: 
http://lists.oasis-open.org/archives/wsbpel/200602/msg00108.html 

> ------------------------------------------------------------------------
> *From:* Danny van der Rijn [mailto:dannyv@tibco.com]
> *Sent:* Wednesday, March 08, 2006 1:50 PM
> *To:* Mark Ford
> *Cc:* wsbpeltc
> *Subject:* Re: [wsbpel] Action Items for undefined behavior
>
> Mark Ford wrote:
>
>> I should have brought this up during the call but I was concentrating 
>> on taking minutes ;)
>>
>> If there are no objections, I will open action items for the 
>> following spec text below that still contains undefined behavior.
>>
>> *#1 undefined changes to bpws:missingReply*
>> 5.5 The Lifecycle of a Business Process
>> (Paragraph 8)
>> A receive activity for an inbound request/response operation is said 
>> to be open if that activity has been performed and no corresponding 
>> reply activity has been performed. If the process instance reaches 
>> the end of its behavior, and one or more receive activities remain 
>> open,* then the status of the instance becomes undefined*. This 
>> condition indicates a modeling error that was not detected by static 
>> analysis.
>>
>
> Given that this is now much better spelled out, I would prefer just 
> removing this paragraph altogether:  It is now not possible for a 
> process to reach the end of its behavior with an open IMA that hasn't 
> caused a fault already.  We may need to move the first sentence 
> defining an open receive, although we'd have to reword it as an open 
> IMA now anyway.
>
>> *Action:* Change to the following:
>> A receive activity for an inbound request/response operation is said 
>> to be open if that activity has been performed and no corresponding 
>> reply activity has been performed. If the process instance reaches 
>> the end of its behavior, and one or more receive activities remain 
>> open,* then the process faults with a bpws:missingReply*. This 
>> condition indicates a modeling error that was not detected by static 
>> analysis.
>>
>>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]