RE: [wsbpel] Issue - 168 - Lost design patterns

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello,

I think the recent discussion will overcomplicate things a bit for evvent handlers with respect to scopes.

I prefer to define, that an eventHandler attached to a scope never sees the correlations (actually the engine does not have to provide them), because changing yarons example 

process
    scope
       eventHandlers
          onEvent ... operation="AsynchUpdate"
             correlations
                correlation set="foo" initiate="no"
             ...
       sequence
          receive ... operation="StartProcess" createInstance="yes"
             correlations
                correlation set="foo" initiate="yes"
          ...


into:

process
       sequence
          receive ... operation="StartProcess" createInstance="yes"
             correlations
                correlation set="foo" initiate="yes"
          scope
             eventHandlers
             onEvent ... operation="AsynchUpdate"
                correlations
                   correlation set="foo" initiate="no"
                ...
          ...

is no problem, and this will "force" the correlation to be valid upon scope instantiation.

I dont think rules like "event handlers are instantiated only if all correlations in the attached scope are instantiated" make BPEL more usefull.

In fact the above solution will even be detectable on deploy time, if you define the correlation set within scopes. In that case the correlation defined inside the scope will be unknown to the handler, which is in fact exactly what we want to have.


Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Friday, October 29, 2004 7:09 PM
To: ygoland@bea.com
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 168 - Lost design patterns


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