New"Bug" - Semantics of instance creation.

[Maciej Szefler <mbs@fivesight.com>]

Discussions of Issue 81 have brought to light a certain deficiency of
clarity in the current specification with respect to issue of instance
creation. The present spec makes various vague and somewhat
contradictory statements as to how createInstance activities should be
handled. 

On the one hand, the spec suggests that process creation is "implicit"
and that the createInstance flag is merely an annotation that defines
which message events cause an instance to be created and that once
created the process instance processes all activities in the same manner
largely oblivious to the value of that annotation. 

On the other hand, the spec restricts the set of activities that are
"initial" activities, and establishes exceptional semantics (for
process-level event handlers) that could be construed to imply that
createInstance activities are actually activated before any other
activities, irrespective of their actual location in the process. 

I posit that the former interpretation provides a concise and manageable
view of the instance creation process. By making the spec consistent
with it we can define execution semantics of a single process instance
without reference to instance creation. We can handle instance creation
simply and separately by stipulating that a process instance is created
when a message event that would match one of the createInstance
activities is received. This message event is "allocated" to that
activity, so that when that activity is actually activated (in the
normal course of process instance evaluation) it will receive the said
event. 

The major implication of this model on execution semantics is the
elimination of the notion of "initiate" activities. This concept becomes
unnecessary. One might object on the basis that without the initiate
activity restrictions the following process would be perfectly legal:
   <sequence>
     <invoke .../>
     <receive createInstance="yes" .../>
   </sequence>
Such a process certainly seems objectionable. However, the details of
normal execution semantics would make such a process unlikely. That is
to say, the <invoke> would need to use a message variable (for the
request), and that variable could not have been initialized unless some
activity preceded the <invoke>. One might then object with the
following:
   <sequence>
     <receive createInstance="no" .. var="foo"/>
     <invoke ... inVar="foo"/>
     <receive createInstance="yes" ..>
   </sequence>
However, in this process the first receive is invalid unless a
correlation set is used. But in order to use the correlation set, it
first needs to be initialized, and the only way to do that is with an
invoke or a receive/pick that precedes it, so you're back to needing a
<receive> to precede the <invoke>. This receive would have to have
createInstance="yes" lest it run into the same problem. But if this
receive had createInstance="yes" then the same annotation on the second
<receive> would be invalid.

Now, one might get cleverer still and object based on the following
somewhat convoluted process: 
   <sequence>
     <assign> 
        <copy>
           <to variable="foo"/>
           <from> literal </from>
        </copy>
     </assign>
     <invoke ... inVar="foo"> 
        <correlation name="cset1" initiate="yes" pattern="in"/>
     </invoke>
     <receive createInstance="no" ..>
        <correlation name="cset1" initiate="no" />
     </receive>
     <receive createInstance="yes" ..>
   </sequence>
However the above construct would result in ALL process instances having
the same correlation set value, which does not make any sense.

But one could still object by changing the pattern to "out" on the
invoke, and asserting that the partner generates unique output messages
for each invocation thereby yielding unique correlation keys. But even
this very brink of the edge case forces us to change nothing in the
semantics. The only significant implication is that in certain unlikely
circumstances, the implementation might have to handle <invoke>s and
non-createInstance <receive> before it has a chance to offload the
createInstance message to the createInstance <receive> (i.e. it needs to
provide a "memory" for the message that created the instance). The only
plausible use case for this kind of behavior is for initialization of
static content. 

Finally, adopting uniform execution semantics would lead us to
elimination of the exceptional language in the spec that requires that
process-level alarm handlers can use data that would normally only be
valid after a receive activity completes. This is not so onerous, as it
is possible to move a process-level event handler into a scope following
the initial receives. 

I submit this as a bug for TC's consideration.

-maciej

This is a digitally signed message part