Re: [wsbpel] Issue 123 - Proposal for vote

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

Hi Danny and Chris,

Please see inline.

Danny van der Rijn wrote:

Further if an open IMA goes out of scope prior to being closed by a reply activity then the scope MUST throw a bpws:missingReply fault.  In other words a scope which declares a partnerLink or messageExchange used by an IMA will not complete normally if that IMA is open when the scope is to complete.

This is issue 221, which is currently open.  I don't either the idea of closing it here, or the particular solution you've chosen.  I suggest that this statement be removed, and we have this discussion in 221.

[a]
Thank you very much for reminding us about Issue 221. 

I prefer resolving both issue 221 and 123 in one shot, since the treatment of missingReply is a very tightly coupled part of Issue 123 resolution.

Here are attempts to refine the semantics of missingReply per questions raised in Issue 221:

Q1: have the process' faultHandlers been uninstalled?
Answer: As I mentioned in the my previous email: (please see the example)
http://lists.oasis-open.org/archives/wsbpel/200512/msg00050.html
I prefer the direction of which: the fault is thrown by scope S2 to scope S2.

That means:

The missingReply checking logic is performed before the fault handlers are uninstalled. That implies, the fault is thrown (if the missingReply checking logic determins the open IMA situation) before the fault handlers are uninstalled.

Q1a: Does this difference have normative meaning?

If a missingReply fault handler presents in the faulted scope, it will be able to catch the missingReply fault.

Q2b: What happens if that fault handler doesn't reply? Does the fault get somehow suppressed the 2nd time around? Does the fault get caught again by that eventHandler? Do we allow an infinite loop?

If the fault handler of missingReply does not generate a proper reply, a new missingReply fault MUST be thrown. Note: there is NO an infinite loop problem. Because, any faults triggered or thrown by a fault handler (e.g. <rethrow> activity) will NOT be caught by any fault handler of the same scope and they can be caught by the parent scope only.

Consolidated writeup: (as the supplementary amendment to the proposal: if we agree with the direction that I am suggesting)

At the end of the paragraph of "If a reply activity cannot be associated with an open IMA ...", add:
==================================
The missingReply checking logic of a scope (S2) is performed after all the normal child activities of the scope (S2) are finished but before the fault handlers are uninstalled. That implies, the fault MUST be thrown (if the missingReply checking logic detects the open IMA situation) before the fault handlers are uninstalled. If a fault handler at the faulted scope (S2) matches bpws:missingReply fault, it will be able to catch the bpws:missingReply fault. Furthermore, if the triggered fault handler does not generate a proper reply, a new missingReply fault MUST be thrown. Note: there is NO an infinite loop situation, because any faults triggered or thrown by a fault handler (e.g. <rethrow> activity) will NOT be caught by any fault handler of the same scope (S2) and they can only be caught by its ancestor scopes (e.g. S1).

Here is a fragment of process definition that illustrates the relationship of scope S1 and S2 described above:
------------------
<scope name="S1">
    ...
    <scope name="S2">
         ...
         <partnerLinks>
             <partnerLink name="pl1" ... />
         </partnerLinks>
         ...
         <sequence>
             <receive partnerLink="pl1" ... />
             <!-- receive without reply -->
         </sequence>
    </scope>
    ...
</scope>
------------------

Note: The bpws:missingReply fault is thrown by scope S2 to scope S2 itself.

==================================

The name used in the optional messageExchange attribute MUST resolve to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the reply activity and its corresponding IMA.  This resolution follows the same scoping rules as variable, partnerLink and correlationSet resolution.

This wording can be easily interpreted to imply that messageExchanges get declared on scopes.  I'm not being too creative as per replacements right now, but something along the lines of "declared in an activity (or the process)"

[b]
How about saying: "MUST resolve to a messageExchange declared in a scope (or a construct which has similar declaration facilities, such as process)".
Just saying "an activity" is too generic.

This resolution follows the same scoping rules as variable, partnerLink and correlationSet resolution.

This resolution follows the same lexical scoping rules as variable, partnerLink and correlationSet resolution.  Note, however, that messageExchanges are declared on different elements than are variable, partnerLink and correlationSet.

[c]
Adding "lexical" wording is good.

However, adding "Note, however, that messageExchanges are declared on different elements than are variable, partnerLink and correlationSet." is too clumsy. So clumsy that it is becoming confusing again. The difference of declaring on different elements are very oblivous to users already.

Default message exchanges are uniquely provided by the process scope, onEvent scope and the immediate child scope of forEach activities marked as parallel

"the immediate child scope" may have to be changed if we adopt 120.something.  If we change this to "the immediate child" or some such we could be ready for 120.x

[d]
Issue 120.2 is targeting onEvent and onAlarm only. The term "the immediate child scope" is applied to "forEach activities". It will NOT be changed even after we pass Issue 120.2.


Thanks!


Regards,
Alex Yiu

Chris Keller wrote:

Below is the updated proposal for vote where a default message exchange has been introduced in the last paragraph.

 

- Chris

 

Issue 123 - Proposed changes to current draft for scoped messageEchange:

 

In section 6.2 add to the informal syntax describing the XML grammar for both the process element and the scope element between partnerLinks and variables the following:

 

<messageExchanges>?

     <messageExchange name="ncname"/>+

</messageExchanges>

 

 

Change the following paragraphs from Section 11.4:

 

The optional messageExchange attribute is used to associate a <reply> activity with an inbound message activity, such as, <receive>, <onMessage> and <onEvent>, when there are multiple simultaneously incomplete inbound message activities which requires a reply message to complete.

 

A reply activity is associated with a inbound message activity based on the tuple - partnerLink, operation, and messageExchange. The value defined in messageExchange is scoped to the combination of partnerLink and operation. That is, it is legal to use the same messageExchange value in multiple simultaneously incomplete receive activities so long as the combination of partnerLink and operation on the receives are all different from each other. An incomplete inbound message activity describes the state of a BPEL process from the point that a request/response receive activity starts execution until its associated reply begins execution.

 

If there should ever be multiple simultaneous incomplete inbound message activities which have the same partnerLink, operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown within the BPEL process on the conflicting inbound message activities subsequent to the execution of the successful incomplete receive.

 

If a reply activity cannot be associated with an incomplete receive activity by matching the tuples and this error situation is not caught during static analysis,  then bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests should have been rejected at the time inbound message activity is executed, there cannot be more than one corresponding inbound message activity at the time <reply> is executed.

 

If the messageExchange attribute is not specified on a receive then its value is taken to be empty. For matching purposes two empty messageExchange values with the same partnerLink and operation values are said to match. Empty value does not match with other non-empty values.

 

 

To the following:

 

A reply activity is associated with an inbound message activity (IMA), such as, <receive>, <onMessage> and <onEvent> based on the tuple - partnerLink, operation, and messageExchange.  The name used in the optional messageExchange attribute MUST resolve to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the reply activity and its corresponding IMA.  This resolution follows the same scoping rules as variable, partnerLink and correlationSet resolution.

 

An open IMA describes the state of a Web service operation from the point that a request/response IMA starts execution until an associated reply begins execution. It is illegal to have multiple simultaneous open IMAs, which have the same partnerLink, operation and messageExchange tuple.  A BPEL process MUST throw a bpws:conflictingRequest fault when the conflicting IMA begins execution.  Note that it is legal to use the same messageExchange in multiple simultaneously open IMAs so long as the combination of partnerLink and operation on the IMAs are all different from each other.

 

If a reply activity cannot be associated with an open IMA by matching the tuples (partnerLink, operation, and messageExchange) then a bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests MUST be rejected at the time the IMA begins execution there cannot be more than one corresponding IMA at the time a reply activity is executed. Further if an open IMA goes out of scope prior to being closed by a reply activity then the scope MUST throw a bpws:missingReply fault.  In other words a scope which declares a partnerLink or messageExchange used by an IMA will not complete normally if that IMA is open when the scope is to complete.

 

If the messageExchange attribute is not specified on an IMA or reply then the activity's messageExchange is automatically associated with a default message exchange with no name.  Default message exchanges are uniquely provided by the process scope, onEvent scope and the immediate child scope of forEach activities marked as parallel.  A default message exchange is created each time the default message exchange provider is executed.  For example each time an onEvent is executed (i.e. when a new message arrives for processing) it creates a new default message exchange. This prevents an onEvent handler, which doesn't specify a messageExchange, for request-reply operations from faulting when a message is received while there is already another instance of the onEvent handler processing a message that has not reached its reply point.  Similarly it allows most parallel forEach receive(or pick)-reply pairs to be described without the need to introduce a messageExchange.  The use of messageExchange for most applications is required only for cases where the execution of a flow can result in receives(or pick)-replies on the same partnerLink and operation executed simulateneously so the application must mark the relationship between the pairs.

 

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php