Re: [wsbpel-spec-edit] text for missingReply (was: Issue Resolutions221, 232, 237)

[Alex Yiu <alex.yiu@oracle.com>]

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