[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 168 - Lost design patterns
Since it is legal to initialize correlation sets as part of an event
handler I would presume your restriction would only apply to correlation
sets that are marked initiate="no"? But this would create its own
strange situations:
scope
eventHandlers
onEvent ...
correlations
correlation set="foo" initiate="no"
flow
...
flow
...
receive ...
correlation set="foo" initiate="yes"
...
...
The event handler wouldn't start to execute until some random point in
the execution of the scope when the related correlation set was
initiated rather than the current semantics which state that event
handlers start as soon as the scope is entered.
I think this 'simplification' really isn't very simply. It requires
non-trivial changes to event handlers and it requires us to talk about
the elephant in order to explain why the model doesn't cause race
conditions amongst start activities.
I think we are better off just specifying that the initial activity
completes before any other activity executes. By using that logic we
don't have to mention the elephant and event handlers work normally.
Yaron
Maciej Szefler wrote:
> Yaron,
>
> I feel your pain ;), but when it comes to your #2 language it's like
> that William Shatner/Henry Rollins duet: "I can't get behind that". If I
> take your process:
>
> process
> scope
> eventHandlers
> onEvent ... operation="AsynchUpdate"
> correlations
> correlation set="foo" initiate="no"
> ...
> sequence
> receive ... operation="StartProcess" createInstance="yes"
> correlations
> correlation set="foo" initiate="yes"
> ...
>
> and now change it slightly:
>
> process
> sequence
> receive operation="TheRealStartOp" createInstance="yes"
> scope
> eventHandlers
> onEvent ... operation="AsynchUpdate"
> correlations
> correlation set="foo" initiate="no"
> ...
> sequence
> receive ... operation="StartProcess" createInstance="no"
> correlations
> correlation set="foo" initiate="yes"
> ...
>
> I now have a process that has no chance of working. This is what makes
> me very uneasy: simply by changing the value of a createInstance from
> "yes" to "no" in a <receive> we get completely different behavior in
> <scope>.
>
> However, this is not to say that there is no way to make everyone happy.
> I certainly would not be opposed to a more general solution. For
> example, I could buy into language along the lines of:
>
> "an event handler is installed as soon as BOTH (1) the scope in which it
> is declared becomes active AND (2) all variables and correlation sets
> used in its declaration are initialized.
>
> Such language would permit both of the processes shown above to
> function, and function in exactly the same way (making me happy). We
> would not have to use language with exceptions for activity completion
> order (again making me happy). As far as your use case, behavior would
> be what you expect, hopefully making you happy.
>
> What do you think?
>
> -maciej
>
> On Wed, 2004-10-27 at 18:08, Yaron Y. Goland wrote:
>
>>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
>>>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>>
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]