Issue 241 - Note for Discussion

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

Hi all,

Here is the note for discussion for Issue 241.

Thanks!

Regards,
Alex Yiu

Title: Issue 241

Note on Issue 241 (Potential Directional Vote Draft)

Last modified: Feb 21, 2005 


Terminology:

• associated scope: the scope directly attached to <onEvent> or <onAlarm> under <eventHandlers>. The semantics of scope is already decided by Issue 204 resolution, while Issue 242 may change the syntax of associated scope.
  
• ancestor scopes: the containing <scope> or <process> or scope-equivalent constructs of <eventHandlers> (depending on resolution of Issue 242)

Resources	Resolving To	Declaration Locally in the Associated Scope
variables [Note #1]	[Currently: resolving to associated scope only] Suggestion: kept the same [Rationale #1]	[Currently: implicit declaration] [Note #2] Suggestion: kept the same [Rationale #1]
partnerLink	[Currently: seem like resolving to ancestor scopes only] Suggestion: resolving to the associated scope first and then ancestor scopes	[Currently: after passing Issue 204, partnerLink can be declared locally] Suggestion: kept the same (maybe with explicit text clarification)
correlation set	[Currently: seem like resolving to resolving to the associated scope first and then ancestor scopes] Suggestion: resolving to the associated scope first and then ancestor scopes (using <correlation> syntax) (maybe with explicit text clarification)	[Currently: CS can be declared locally] (using <correlationSet> syntax) Suggestion: kept the same
messageExchange	There were two options discussed during F2F: [Note #3] same as variable same as correlationSet/partnerLink	[Currently: MsgExchange can be declared locally, including the default message exchange] Suggestion: kept the same

Note #1: Variables include all these cases:

• messageType variable: using messageType="..." syntax
  
• element-based variable of single-part doc-lit message: using element="..." syntax
  
• simple, complex type, element based variables: using <fromPart> syntax
  

Note #2: Definition of Implicit Variable Declaration:

• Current spec text:
• "The variable attribute identifies a variable local to the eventHandler that will contain the message received from the partner."
• "Optionally the messageType attribute may be omitted and instead the element attribute substituted if the message to be received has a single part and that part is defined with an element type that matches the element type referenced by the element attribute."
• "When using the <fromPart> elements, each <fromPart> element constitutes a declaration of a variable of that name within an implicit scope associated with the event handler. The variable type is derived from the type of the corresponding message part."
  

Rationale #1:  [decision point here]

• Implicit variable declaration and resolving to the associated scope only (current spec behavior) will ensure that multiple instances of <onEvent> has its own local copy of variables of recieved messages.
  
• If we allow resolution to the parent scope of variable used in <onEvent>, then multiple instances of <onEvent> will be more than likely to "share" the same variable of received messages and the received message will overwrite each other during multiple instantiation of <onEvent>.
    ==> That is almost equivalent asking users to get a stone to throw at their own feet
    ==> Why allowing usage pattern which is harmful ranther than useful to users??
  
• Implicit variable declaration also save users from writing redundant codes, especially in the case of <fromPart>. If we want to achieve implicit variable declaration, it would be better to have variables resolved to the associated scope only. Otherwise, the semantics would be surprising/mysterious to users, if a variable of same name is declared in an outer scope.
  
• About comparision with using a <receive> within a parallel forEach, I would not say they are equivalent. Variables in an <onEvent> is like parameters of a method call, where multiple calls can happen concurrently and each call should have its own copy of parameter. On the other hand, variables used in <receive> in a parallel forEach is similar to calling another service call that modifies data in a parallel env. In most of programming languages, the first pattern is enforced by the programming language design itself. On the other hand, if a same variable is shared among multiple parallel service call, a good language envirnoment would warn users about that to its best extent. That is especially true to a high-level language like BPEL.
  

Note #3: There were two options discussed during F2F:  [decision point here]

      
(A) same as variable: Assuming
variable is resolved to associated scope only. That means the
messageExchange is resolved to associated scope only.
(B) same as correlationSet/partnerLink: That means the messageExchange can be resolved to a parent scope
F2F attendents seem like preferring this one (B) so far.

[AYIU: IMHO, I am wondering
what is a legal usage patter for (B)?  Can we construct a general
legal case? I don't need a meaningful one but just a legal one.

• Using a while or forEach loop to reply the <onEvent>? It does not seem to work.
• Using another <onEvent> to reply? It does not seem to work either.
  
• Unless all the <onEvent> call is serialized, I cannot find a legal usage case so far. If the incoming call is known to be serialized, a <receive> within <while> loop should be used instead.]
  

Minor adjustment of  Issue 123 Resolution: 

When I was proposing the amendment to Chris' proposal on Issue 123 to drop "partnerLink" from the list: 
http://lists.oasis-open.org/archives/wsbpel/200512/msg00050.html
because I was aware that partnerLink resolution is different from variable.

Unfortunately, I was not aware that the resolution of variables and
correlation set in the current spec text is different at that time. If I was
aware that at that time, I would suggest just listing variable in the
resolution rule in Issue 123 proposal. 

One way or the other based on the decision point on  [Note #3]. I suggest to clarify Issue 123 resolution. 

From: "This resolution follows the same scoping rules as variable and
correlationSet resolution."
To: "This resolution follows the same scoping rules as variable resolution."

OR:  

From: "This resolution follows the same scoping rules as variable and
correlationSet resolution."

To: "This resolution follows the same scoping rules as correlationSet resolution."

END