My interpretation is that it's
5 Both 2 & 3 are correct, with the scope farthest 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.)
When the innermost of the partnerLink and messageExchange scopes goes
out of scope, the IMA is no longer closeable. If this isn't stated
somewhere explicitly, it needs to be.
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:
- Its the scope of the activity, the same of any other activity.
- 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.
- 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.
- 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.)
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.
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
|