OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [no subject]


I would also disagree with the suggestion that parallel event handling is
unnecessary; I find this to be one of the most important features of the
event handling mechanism, without it there is no way to do long-running
request processing against a single BPEL process instance like "request
notification when process is half filled" or "handle bids from many
suppliers". Granted there may be problems in implementing these uses cases
in any case, but eleminating parallel event handling will certainly make
them impossible.

-maciej

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Sun 9/21/2003 3:27 PM
To: 'Francisco Curbera'
Cc: Maciej Szefler; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler



             +1. adding messageType to onMessage would be enough. But there
is a side
             effect. We need to differentiate pick/onMessage and
eventHandlers/onMessage.
             Meaning we need a new name for eventHandlers/onMessage
             Edwin

             > -----Original Message-----
             > From: Francisco Curbera [mailto:curbera@us.ibm.com]
             > Sent: Sunday, September 21, 2003 10:00 AM
             > To: edwink@collaxa.com
             > Cc: 'Maciej Szefler'; wsbpel@lists.oasis-open.org
             > Subject: RE: [wsbpel] Issue 36 - Multiple instances of event
handler
             >
             >
             >
             >
             >
             > It seems that the intended semantics we want to attach to
the
             > variable attribute in onMessage corresponds to that of an
             > argument in a funcion/method declaration. That is, the
             > variable is declared by its appearing in the onMessage
             > statement itself; we are only missing the "type"
             > statement.
             >
             > I guess this is also consistent with the catch model Edwin
mentions.
             >
             > Paco
             >
             >
             > This is consistent with the
             >
             >
             >

             >

             >                       "Edwin

             >

             >                       Khodabakchian"           To:
             > "'Maciej Szefler'" <mbs@fivesight.com>,
             > <wsbpel@lists.oasis-open.org>
             >                       <edwink@collaxa.c        cc:

             >

             >                       om>                      Subject:  RE:
             > [wsbpel] Issue 36 - Multiple instances of event handler

             >

             >

             >                       09/19/2003 03:25

             >

             >                       PM

             >

             >                       Please respond to

             >

             >                       edwink

             >

             >

             >

             >
             >
             >
             >
             > This reverse scope resolution seems a little bit black magic
             > to me. It we decide not to go down the path of serialization
             > because of sync performance issue, I think that we should
             > look at the syntax of catch. This will create the need to
             > have a separate syntax for onMessage in eventHandlers and
             > onMessage in pick. But it could be a good thing.
             > Edwin
             >
             > > -----Original Message-----
             > > From: Maciej Szefler [mailto:mbs@fivesight.com]
             > > Sent: Friday, September 19, 2003 10:24 AM
             > > To: wsbpel@lists.oasis-open.org
             > > Subject: [wsbpel] Issue 36 - Multiple instances of event
handler
             > >
             > > Per the discussion at the face-to-face. My original though
here was
             > > the the implicit scoping present in the BPEL syntax was
responsible
             > > for this problem because it did not allow us to declare
the message
             > > variable in the "most local" scope of the onMessage
             > handler. I won't
             > > go into too much detail because as Satish pointed it out
             > this premise
             > > is valid only if onMessage were an activity, and it is
not.
             > >
             > > So, although I still think the syntax is still a bit
             > confusing as to
             > > scopes and activities (a <scope> is an activity without an
implicit
             > > scope, and all other activity have an implicit scope,
             > except that in
             > > the implicit scope you cannot define variables, and
             > correlation sets,
             > > etc...), it is not responsible for this problem.
             > >
             > > Which brings me to the proposed solution; I still don't
like it.
             > > Saying that a "copy" of the input variable in the
onMessage
             > handler is
             > > made for each instance of the handler sounds like a hack,
             > and confuses
             > > the operational semantics. I think what we are trying to
             > say here is
             > > that the /name/ of the input message variable is
/resolved/
             > not in the
             > > scope that contains the event handler, but in the scope of
the
             > > activity started by the onMessage event. For example:
             > >
             > > <scope name="S">
             > >    <!-- no variables declared -->
             > >    <eventHandler>
             > >    <onMessage variable="foo">
             > >       <scope name="SE">
             > >          <variable name="foo" />
             > >           ....
             > >       </scope>
             > >    </onMessage>
             > >    </eventHandler>
             > > </scope>
             > >
             > > In the above case because the name "foo" is evaluated in
             > the scope of
             > > the activity specified for the onMessage event, multiple
             > instances of
             > > the event will not use the same variable instance. In the
following
             > > case:
             > >
             > > <scope name="S" >
             > >    <variable name="foo" />
             > >    <eventHandler>
             > >      <onMessage variable="foo">
             > >        <activityX>
             > >      </onMessage>
             > >    </eventHandler>
             > > </scope>
             > >
             > > the variable "foo" will be shared by all instances of the
onMessage
             > > event handler, as the implicit scope of "activityX"
             > > does not define the "foo" variable and so we'll go to the
             > parent scope
             > > to resolve it, leading to resolution in scope "S" which is
shared.
             > >
             > > I believe adopting the above language is cleaner in terms
of
             > > operational semantics: fundamentally if the variable is
used in the
             > > event handler it should not be declared in an enclosing
scope, its
             > > like using a global variable to pass an argument to a
function. the
             > > price is having to declare a scope as the activity for the
             > onMessage
             > > event (although if we could define a <variable> in the
             > implicit scope
             > > of an activity this would not be necessary).
             > >
             > > -maciej
             > >
             > >
             > > > -----Original Message-----
             > > > From: jevdemon@microsoft.com
[mailto:jevdemon@microsoft.com]
             > > > Sent: Friday, September 19, 2003 10:23 AM
             > > > To: wsbpel@lists.oasis-open.org
             > > > Subject: [wsbpel] Groups - f2f-notes-9-18.doc uploaded
             > > >
             > > >
             > > > The document f2f-notes-9-18.doc has been submitted by
John Evdemon
             > > > (jevdemon@microsoft.com) to the OASIS Web Services
             > Business Process
             > > > Execution Language TC document repository.
             > > >
             > > > Document Description:
             > > > Sid's notes from yesterday morning.  Consider these to
be "draft"
             > > > minutes...
             > > >
             > > > Download Document:
             > > >
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.p
             > > hp/3565/f2f-notes-9-18.doc
             > > >
             > > > View Document Details:
             > > >
http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.p
             > > > hp?document_id=3565
             > > >
             > > >
             > > > PLEASE NOTE:  If the above links do not work for you,
your email
             > > > application may be breaking the link into two pieces.
You
             > > may be able
             > > > to copy and paste the entire link address into the
             > address field of
             > > > your web browser.
             > > >
             > > > -OASIS Open Administration
             > > >
             > > >
             > > > 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/le
             > > ave_workgroup.php.
             > >
             > >
             > > 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/le
             > > ave_workgroup.php.
             > >
             > >
             >
             >
             > 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/le
             > ave_workgroup.php
             > .
             >
             >
             >
             >







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]