Re: [wsbpel] A possible issue concerning the definition of IMA scope

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

Hi, Ron,

Besides 10.4.1, another relevant part of IMA and message exchange handling is in section 12.2:
------------------------

12.2. Message Exchange Handling

When the primary activity and the event handlers of a <scope> complete then all Web service interactions dependent on partner links or message exchanges declared inside of the <scope> need to be completed. An orphaned IMA occurs when an IMA using a partner link or message exchange, declared in the completing <scope> or its descendants, remains open.  ....
------------------------

If we do a brief update in 10.1.4
from:
-----------------------
Further if an open IMA goes out of scope prior to being closed
-----------------------
to:
-----------------------
Further if an open IMA goes out of scope (known as an orphaned IMA) prior to being closed
-----------------------
 from:
-----------------------
(see section 12. Scopes for other details of bpel:missingReply).
-----------------------
to:
-----------------------
(see section 12.2 Message Exchange Handling for other details of bpel:missingReply and orphaned IMA).
-----------------------

then, it may improve ease of understanding.


Please see more inline:

Ron Ten-Hove wrote:

An IMA has associated with it three scopes, two of which are associated with its identity:

• The scope in which the IMA itself is defined
• The scope of its partnerLink
• The scope of its messageExchange name (including default name, of course)
  

This leads to a question: when we speak of the "scope of an IMA", what precisely do we mean? Section 10.4.1 doesn't really answer this, and I've heard good arguments for a variety of definitions for IMA scope:

1. Its the scope of the activity, the same of any other activity.
2. Its the scope of the partner link. IMAs are special, and must be paired with a <reply>, so the association between the IMA and <reply> logically belongs to the partnerLink. It follows that the IMA belongs to the partnerLink, and thus its scope.
   
3. Its the scope of the messageExchange name shared between the IMA and the <reply>. This name (even if it is the default name) indicates the association between the IMA and the <reply>, and thus the IMA logically belongs to the ME name's scope.
4. Both 2 & 3 are correct, with the scope closest to the root (process) scope being the correct choice if the partnerLink and messageExchange are not in the same scope. (They both must be enclosing scopes for both the IMA and the <reply> activities.)
   

[AYIU]: I have not found the exact usage of term "scope of an IMA". But I do find the usage of "an open IMA goes out of scope". I hope my above suggestion make it easier to read and understand.

I think the answer is definitely not choice #1. The answer will be the fifth one, as indicated in section 12.2: the closest scope to the IMA activity, if partnerLink and messageExchange are declared in different scopes.

Because, <reply> activities need both partnerLink and messageExchange (maybe implicit) to match an IMA.

As an illustrative (and abbreviated) example:

process
   partnerLink foo
   messageExchange bar
   sequence
      scope X
         ...
         receive partnerLink foo messageExchange bar
         ...
      ...
      reply partnerLink foo messageExchange bar
  

Case 1 would deem this to be an invalid process, for when scope X completes, it will hold an open IMA, causing a bpel:missingReply fault. In cases 2-4, this would be considered valid, since the <receive> IMA belongs to the process scope.

[AYIU]: The above example is definitely a valid process.

My question for the TC is this: what is the scope of an IMA? Have I missed the appropriate text in the spec that clarifies this, should we add a clarification, presumably in section 10.4.1? If clarification is necessary, what will our definition of IMA scope be?

-Ron

[AYIU]:
I tend to think the description in description in 12.2  is clear enough. IMHO, we may not need any new big paragraph. A refinement of cross reference should be good enough.


Thanks!


Regards,
Alex Yiu