Re: [wsbpel] Issue - 32 - Link Semantics in Event Handlers

[Francisco Curbera <curbera@us.ibm.com>]

Dieter,

I was suggesting serializing the processing of the successive invocations
of each onMessage, not of all handler invocations. That is, onAlarms and
each of the onMessage handlers would be allowed to execute concurrently,
but only one instance of each handler would be executing at a given time.
This is not a principled position, just that I don't know of any
compelling example to justify the complexity of allowing concurrent
processing (again, of the different invocations of one and the same
handler.)

Paco



                                                                                                                                        
                      "Dieter Roller"                                                                                                   
                      <ROL@de.ibm.com>         To:       "Yuzo Fujishima" <fujishima@bc.jp.nec.com>                                     
                                               cc:       Francisco Curbera/Watson/IBM@IBMUS, wsbpel@lists.oasis-open.org                
                      07/07/2003 09:03         Subject:  Re: [wsbpel] Issue - 32 - Link Semantics in Event Handlers                     
                      AM                                                                                                                
                                                                                                                                        





I'm against any serialization. It introduces a restriction that is not
needed and in fact can make things just more complicated. Suppose we have
the following definition :


<eventHandlers>

 <onMessage>

</onMessage>

<onAlarm>

</onAlarm>

a message has arrived and is processed by the activity in the onMessage
event handler and the onAlarm is ready to go off. What would we do : wait
with the alarm until the message has been processed ?

I'm confident other people will find other examples where serialization
hurts...


Cheers,

dieter



Dieter Roller
IBM Senior Technical Staff Member (STSM)
Member IBM Academy of Technology
Phone :                 +49-7031-164476
Fax :                    +49-7031-164890
e-mail                   rol@de.ibm.com



|---------+---------------------------->
|         |           "Yuzo Fujishima" |
|         |           <fujishima@bc.jp.|
|         |           nec.com>         |
|         |                            |
|         |           07/07/2003 07:39 |
|         |           AM               |
|         |                            |
|---------+---------------------------->

>--------------------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       Francisco Curbera/Watson/IBM@IBMUS
|
  |       cc:       <wsbpel@lists.oasis-open.org>
|
  |       Subject:  Re: [wsbpel] Issue - 32 - Link Semantics in Event
Handlers                                                                 |
  |
|
  |
|

>--------------------------------------------------------------------------------------------------------------------------------------------|




Paco,

I, too, would vote for serialization for the same reason.

Yuzo

> Satish's and Edwin's interpretations match mine, and I've always believed
> that to be the original intent of all the authors (who should correct me
if
> I am wrong). On the other hand, it is a fair question to ask whether we
> really need to allow multiple "copies" of an event handler to execute
> concurrently, as opposed to serializing the handling of each message
> received by the handler's onMessage activity. I would vote for
> serialization (of each execution of the same handler) if only because I
> don't have any scenario in mind that justifies the complexity of full
> concurrent execution of multiple copies of the same handler.
>
> Paco
>
>
>
>
>                       "Yuzo Fujishima"
>                       <fujishima@bc.jp.        To:
<wsbpel@lists.oasis-open.org>
>                       nec.com>                 cc:
>                                                Subject:  Re: [wsbpel]
Issue - 32 - Link Semantics in Event Handlers
>                       07/04/2003 09:14
>                       PM
>
>
>
>
>
> Chunbo, Edwin
>
> According to a messge from Satish,
> http://lists.oasis-open.org/archives/wsbpel/200305/msg00131.html
> Edwin's view seems to be closer to the original authors' intention.
>
> The problem is that the specification itself allows at least two
> interpretations. I raised this issue to clarify which is the right one.
> After the discussion and the issue/requirementprocess mature,
> I probably propose a motion to pick one iterpretation.
>
> Yuzo
>
>
> Chunbo> Hi Yuzo,
> Chunbo>
> Chunbo> I think the link status is maintained at process instance level,
> not based
> Chunbo> on the thread level.  So A and B will be synced as far as they
> belong to the
> Chunbo> same process instance.
> Chunbo>
> Chunbo> -Chunbo
>
> Edwin> Yuzo,
> Edwin> Thank you for the example. It seems that in that specific case,
each
> message
> Edwin> would create a new flow activity. So if you have 4  messages, you
> end up
> Edwin> with 4 instances of the flow activity (all running concurrently).
> Each flow
> Edwin> activity instance will have its own AtoB link. No?
> Edwin> Edwin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org






---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org