[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 32 - Link Semantics in Event Handlers
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]