[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 168 - Lost design patterns
I'll address the specifics below but I think you've done a great job of
showing that the key issue is event handlers so I'll start with them.
process
scope
eventHandlers
onEvent ... operation="AsynchUpdate"
correlations
correlation set="foo" initiate="no"
...
sequence
receive ... operation="StartProcess" createInstance="yes"
correlations
correlation set="foo" initiate="yes"
...
The previous does not strike me as being particularly strange. But with
the current proposal the previous is somewhere between illegal and
unreliable. I realize that the previous can always be re-written as
process
sequence
receive ... operation="StartProcess" createInstance="yes"
correlations
correlation set="foo" initiate="yes"
scope
eventHandlers
onEvent ... operation="AsynchUpdate"
correlations
correlation set="foo" initiate="no"
...
...
But the previous strikes me as unnatural. The whole point of event
handlers is to allow one to declare a scope and then say 'for anything
in this scope here is an event handler'. I don't see why start
activities shouldn't be allowed to take full advantage of all of a
scope's facilities including event handlers.
I think the issue boils down not to a technical issue but rather to a
design preference. The choices I see before the group are:
Choice #1 - Specify that when a process instance starts all initial
activities begin execution simultaneously.
Pro - Consistent process execution model
Con - Can't use event handlers on scopes that contain start activities
Requires us to talk about the elephant when describing
why this model doesn't cause race conditions amongst multi-starts
Choice #2 - Specify that when a process instance starts the
initialization activity is guaranteed to finish before any other
activity begins executing.
Pro - Makes it possible to use event handlers on scopes
Can't cause race conditions amongst multi-starts so there
is no need to talk about the elephant
Con - Requires special behavior for start activities
I personally prefer choice #2.
I agree with your analysis of the multi-start race condition. As I
mentioned in my original letter the Elephant will resolve the issue.
However, I do like the idea of guaranteeing that initialization activity
will complete before the rest of the process starts executing because it
allows us to resolve the multi-start race condition without having to
even mention the elephant.
In other words, the multi-start race condition will always be resolved
it's only an issue of the need to resort to either the elephant or the
special initial activity behavior. I personally prefer the later but
recognize both work.
I also agree with your analysis of the initial receives that are not
start activities case. It is just a specific example of the more general
problem of executing non-rendezvous receives that use correlation sets
initialized by previously executed rendezvous based receives. I
therefore withdraw this scenario for consideration for issue 168.
Yaron
Maciej Szefler wrote:
> Yaron, see comments below.
> On Mon, 2004-10-25 at 15:20, Yaron Y. Goland wrote:
>
>>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.
>
> I would say that it is legal but is very likely to throw an
> uninitialized correlation fault. This puts it in the realm of "bad code"
> (legal but not advisable).
>
>
>
>>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.
>
> I'm not sure there is a visible race in the multi-start case. It is true
> that if two messages arrive at nearly the same time it is a race as to
> which message is the "instantiating message". However, as far as the
> process is concerned, it does not matter which of the two messages
> instantiated the process (i.e. the process will proceed in exactly the
> same way regardless of which message caused the instantiation). The
> elephant knows that the two multi-start activities are related (because
> they both have initiate='rendezvous' and they both share the same
> correlation set) and ensures that the "loosing" activity is delivered
> messages with the same correlation key as the instantiating message.
>
> Basically this means that "loosing" receives with initiate='rendezvous'
> do not depend on the /correlation set/ being properly initialized at the
> time they are enabled/activated as do receives with initiate='no'. In
> other words: with initiate='yes' you are "initiating" the correlation
> set, with initiate='no' you are "following" the (initialized)
> correlation set, but with initiate='rendezvous' you are NOT "sometimes
> following" and "sometimes initiating" but rather "rendezvousing" (for
> lack of a better word), an operation that ensures that after either the
> looser or winner completes the correlation set is set.
>
> An example might be useful:
> process
> flow "f1"
> sequence "s1"
> receive "r11" op="foo" createInstance="yes"
> correlation set = "foo" initiate = "rendezvous"
> receive "r12" op="baz" createInstance="no"
> correlation set = "foo" initiate = "no"
>
> sequence "s2"
> receive "r21" op="bar" createInstance="yes"
> correlation set = "foo" initiate = "rendezvous"
> receive "r22" op="baz" createInstance="no"
> correlation set = "foo" initiate = "no"
>
> It is important to note that the above process will always work (it
> won't have uninitialized correlation faults) regardless of whether the
> "foo" receive or the "bar" receive is the instantiating activity. The
> "elephant" might even choose the following execution path:
>
> 1. receive msg#1 op=foo key=123
> 2. receive msg#2 op=bar key=456
> 3. receive msg#3 op=bar key=123
> 4. create instance (instantiating message = msg#1 [key=123])
> 5. f1
> 6. s2
> 7. receive msg#4 op=baz key=123
> 8. r21 returns msg#3 op=bar key=123 / "foo" is initialized!
> 9. r22 returns msg#4 op=baz
> 10. s1
> 11. r11 returns msg#1 (**instantiating message**)
> 12. r12 WAITS
> ----
>
> Note that in the above, the "loosing" receive activity was evaluated
> /before/ the receive that got the "instantiating message". This is
> acceptable, given <flow> semantics. Despite this fact, and r22 was free
> to depend on correlation set "foo" which is guaranteed to be initialized
> after /any/ of the rendezvous activities complete. If in step #4, the
> elephant decided to use msg#3, it would not have made any difference.
>
>
>
>>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 I imagine it, the event handler would become active when that scope
> instance became active, which may be before the initiating activity is
> active. It is unlikely that such an event handler would be useful, as it
> could not rely on the data of the initiating activity being set. So
> typically, a process-level event handler would not make any sense.
>
>
>>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.
>
> Yes, but I would argue that this problem has nothing to do with the
> createInstance scenario. The problem you are describing is true of any
> rendezvous situation. For example:
>
> process
> sequence
> receive createInstance=yes...
> ...
> flow
> receive op=buy
> correlationset name=foo initiate=rendezvous
> receive op=sell
> correlationset name=foo initiate=rendezvous
> receive op=authorize
> correlationset name=foo initiate=no
>
> In the above, I would like the fourth receive (op=authorize) to not
> occur until either the second or third occur. I can't draw links because
> there are two sources for the link. This seems to me to be exactly the
> problem you describe. My solution would be two wrap the two rendezvous
> in a flow and draw link between that flow and the third receive. The
> same solution I would apply to your case.
>
>
>>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.
>
> I agree that these use cases are valid, and current BPEL syntax makes
> them difficult to model. However, I'd much prefer a solution to the
> underlying problem (i.e. the lack of multi-source/dynamic links). I
> believe addressing the issue in the limited context of createInstance
> activities is going to introduce an unsightly inconsistency in behavior
> and at the same time won't get to the heart of the problem.
>
> -maciej
>
>
>
>
>> What do you think?
>>
>> Yaron
>>
>>
>>Maciej Szefler wrote:
>>
>>>I propose we adopt the "less magic" approach described in the issue
>>>description. This means that the semantics of process instantiation
>>>would be as follows:
>>> 1. The arrival of message that matches an activity marked with
>>>createInstance=yes/rendezvous (and not matching an existing process
>>>instance) causes a new process instance to be created. This message is
>>>termed the "instantiating message" for that process instance. The
>>>createInstance=yes/rendezvous activity that was used to justify the
>>>instantiation is termed the "instantiating activity" for that process
>>>instance.
>>> 2. Once a process instance is created, all its activities are executed
>>>in the order dictated by the structure of the process.
>>> 3. When a <receive> or <pick> activity with createInstance=yes is
>>>executed, the message "received" will be the "instantiating message" of
>>>the process instance.
>>> 4. When a <receive> and <pick> activity with createInstance=rendezvous
>>>is executed, the message "received" will be either:
>>> a ) the "instantiating message" if said activity is the
>>>"instantiating activity"
>>> b ) some other message matching the correlation key from the
>>>"instantiating message" if said activity is not the "instantiating
>>>activity"
>>>
>>>Key changes to text:
>>>6.4:
>>>OLD: This is done by setting the createInstance attribute of such an
>>>activity to "yes". When a message is received by such an activity, an
>>>instance of the business process is created if it does not already exist
>>>(see Providing Web Service Operations and Pick).
>>>NEW: This is done by setting the createInstance attribute of such an
>>>activity to "yes". When a message that matches such an activity is
>>>received, an instance of the business process is created if it does not
>>>already exist (see Providing Web Service Operations and Pick).
>>>
>>>OLD: To be instantiated, each business process must contain at least one
>>>such "start activity." This must be an initial activity in the sense
>>>that there is no basic activity that logically precedes it in the
>>>behavior of the process.
>>>NEW: To be instantiated, each business process must contain at least one
>>>such "start activity." ----strike---
>>>
>>>11.4:
>>>OLD: A receive activity annotated in this way MUST be an initial
>>>activity in the process, that is, the only other basic activities may
>>>potentially be performed prior to or simultaneously with such a receive
>>>activity MUST be similarly annotated receive activities.
>>>NEW: -----strike----
>>>
>>>
>>>13.5.3:
>>>OLD: If the event handler is associated with the global process scope,
>>>the event handler is enabled as soon as the process instance is created.
>>>The process instance is created when the first receive activity that
>>>provides for the creation of a process instance (indicated via the
>>>createInstance attribute set to "yes") has received and processed the
>>>corresponding message. This allows the alarm time for a global alarm
>>>event to be specified using the data provided within the message that
>>>creates a process instance, as shown in the following example:
>>>
>>>NEW: If the event handler is associated with the global process scope,
>>>the event handler is enabled as soon as the process instance is created.
>>>Note: alarm time for a global alarm event /cannot/ be specified using
>>>the data provided within the message that creates a process instance!
>>>
>>>On Mon, 2004-10-04 at 17:14, ws-bpel issues list editor wrote:
>>>
>>>
>>>>This issue has been added to the wsbpel issue list with a status of
>>>>"received". The status will be changed to "open" if the TC accepts it
>>>>as identifying a bug in the spec or decides it should be accepted
>>>>specially. Otherwise it will be closed without further consideration
>>>>(but will be marked as "Revisitable")
>>>>
>>>>The issues list is posted as a Technical Committee document to the
>>>>OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC
>>>>document, is the most recent version of the document entitled in the
>>>>"Issues" folder of the WSBPEL TC document list - the next posting as a
>>>>TC document will include this issue. The list editor's working copy,
>>>>which will normally include an issue when it is announced, is
>>>>available at this constant URL.
>>>>Issue - 168 - Semantics of instance creation
>>>>Status: received
>>>>Date added: 4 Oct 2004
>>>>Categories: State management
>>>>Date submitted: 30 September 2004
>>>>Submitter: Maciej Szefler
>>>>Description: Discussions of issue 81 : Are start activities that
>>>>aren't createInstance activities legal? 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.
>>>>Changes: 4 Oct 2004 - new issue
>>>>
>>>>______________________________________________________________________
>>>>
>>>>To comment on this issue (including whether it should be accepted),
>>>>please follow-up to this announcement on the
>>>>wsbpel@lists.oasis-open.org list (replying to this message should
>>>>automatically send your message to that list), or ensure the subject
>>>>line as you send it starts "Issue - 168 - [anything]" or is a reply to
>>>>such a message. If you want to formally propose a resolution to an
>>>>open issue, please start the subject line "Issue - 168 - Proposed
>>>>resolution", without any Re: or similar.
>>>>
>>>>To add a new issue, see the issues procedures document (but the
>>>>address for new issue submission is the sender of this announcement).
>>>>
>>>>Choreology Anti virus scan completed
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]