OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue - 168 - Lost design patterns


This is the e-mail that I sent Maciej about my concerns regarding issue 168:

process
   flow
      receive createInstance="yes"
         correlations
            correlation set = "foo" initiate = "yes"
      receive createInstance="no"
         correlations
            correlation set = "foo" initiate = "no"

In the old world order the previous would have been illegal since an 
initial activity appears to need to be a start activity and the second 
receive is not a start activity.

In the new world order is the previous illegal? For example, if an 
engine knows that it will always execute the initiating activity before 
anything else then it can always execute the previous. If an engine 
isn't sure it will complete the initiating activity before executing 
other activities then it might either reject the process statically or 
throw a runtime error.

There is a similar possible race condition between multi-start 
activities although one can argue that the elephant in the room (i.e. 
the dispatcher) will always handle that.

There is also a race condition between event handlers and start 
activities in the new design if the event handler is defined on a scope 
that contains the initiating activity. In other words, it may prove to 
be impossible to ever define an event handler on a scope that contains a 
start activity and be sure what the result would be.

As a general design pattern, I would imagine that anytime there is an 
initial receive/pick (including event handlers) that isn't a start 
activity then it must depend on a correlation set initialization caused 
by the initiating activity. If we don't clearly specify that an 
initiating activity always completes before any other initial activities 
are executed then we make that design pattern effectively impossible.

I don't like the idea of losing the initiating non-start receive 
activity design pattern and it doesn't seem to me like a big deal to 
just require that the initiating activity completes before any other 
activity is executed. I especially like it because it neatly resolves 
the multi-start race condition and so lets us ignore the elephant.

     What do you think?

         Yaron


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]