[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-spec-edit] text for missingReply (was: Issue Resolutions 221, 232, 237)
Hi Alex, I am ok with the direction, but I think there is even more room
for improvement w.r.t. the terminology.
(1) Either use "receive" as a placeholder for all types of inbound message
activities, or define & use the term "inbound message activities" itself.
(2) Either use "open inbound message activity" (my favorite) or "incomplete
inbound message activity", not both.
If there is no objection, a new action item can address this as well.
Kind Regards
DK
Alex Yiu
<alex.yiu@oracle.
com> To
Dieter Koenig1/Germany/IBM@IBMDE
28.02.2006 07:29 cc
Francisco Curbera
<curbera@us.ibm.com>,
wsbpel-spec-edit@lists.oasis-open.o
rg, Diane Jordan <drj@us.ibm.com>,
Alex Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel-spec-edit] text for
missingReply (was: Issue
Resolutions 221, 232, 237)
Hi DK,
Dieter wrote:
I added a new paragraph at the end of 10.4 because the
missingReply was no longer mentioned (!) after the restructuring. I
then
added the 221 resolution text to the end of the main section in
chapter 12
(i.e. before 12.1.).
Thank you for reminding us about that.
About the new paragraph that you added, I have some minor suggestions:
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 standard fault bpws:missingReply MUST be thrown by a
conforming implementation.
It does not mention detailed logic in section 12 "Scopes". The text was
from the description of missingReply, which is not linked/updated with
resolution Issue 221. I suggest make some minor modification to Section
10.4 and Section 12 to link these paragraphs together:
New text for Section 10.4:
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 or scope instance
reaches the end of its behavior, and one or more receive activities
are detected open, then the standard fault bpws:missingReply is
thrown by a conforming implementation. For details of detection
semantics of open inbound message operation, please refer to Section
12 "Scopes".
Since the detailed logic resides in Section 12, we'd better avoid
duplication normative terms (e.g. "MUST be") here.
In Section 12, we would need to modify the text a little bit for
generalization to connect with Section 10.4.
From:
When a scope reaches the end of its behavior then all Web service
interactions dependent on partner links or message exchanges declared
inside of the scope must be completed. The standard fault
bpws:missingReply can be detected during termination of a scope, if
one or more receive operations using a partner link or message
exchange defined in the scope remain open.
To:
When a scope or process instance reaches the end of its behavior then
all Web service interactions dependent on partner links or message
exchanges declared inside of the scope or process instance must be
completed. The standard fault bpws:missingReply can be detected
during the end of a scope or process, if one or more receive
operations using a partner link or message exchange defined in the
scope remain open. Please note that the "scope" term used in the rest
of missingReply detection and generation semantics are applicable to
process as well for brevity, except bullet point number 4, as
process definition does not have a termination handler.
Note: I replace "termination of a scope" with "the end of a scope". As I
suggested before "termination of a scope" has loaded meaning in BPEL spec.
We need to use that term carefully. Sorry that I missed that part during
the review of Issue 221 resolution.
How does that sound to people?
If sounds good, I will file an A.I. with the link pointing back to this
email.
Thanks!!!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Hi Paco, I am done with spec editing for 221, 232, 237 ====> THE PEN
IS
YOURS (current version is 1.112)!
Notes to the whole spec editing team:
Re 221: after restructuring the spec, the anchor point (in former
section
14.4) was lost. I added a new paragraph at the end of 10.4 because
the
missingReply was no longer mentioned (!) after the restructuring. I
then
added the 221 resolution text to the end of the main section in
chapter 12
(i.e. before 12.1.).
Re 232: I changed the repeatUntil activity description according to
the
issue resolution. Note that there is almost identical text in two
places.
Re 237: I changed the if activity description according to the issue
resolution. I also changed an example that still contained the switch
(!)
activity.
Kind Regards
DK
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]