I would like to second Yaron's request. The ability to locally define
partner links increased the isolation of scopes. - Edwin
> -----Original Message-----
> From: Yaron Goland [mailto:]
> Sent: Wednesday, October 22, 2003 1:52 PM
> To: 'Harvey Reed'
> Cc: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
> Subject: RE: [wsbpel] Issue - 75 - Do we need locally
> declared partnerLinks?
>
> I suspect the most common scenario is also one of the key
> motivating scenarios for languages to add things like locally
> scoped variables and public/private/protected modifiers -
> Programmer error.
>
> Currently partnerLinks must be global and must be statically
> defined. In any case where there is an indeterminate number
> of partners to speak with it will be necessary to re-use
> existing partnerLinks. This means programmers will be quite
> used to looking at the top of their BPEL files and re-using
> partnerLinks already defined there.
>
> In a perfect world with perfect programmers there will never
> be mistakes and no one will ever mistakenly re-use a
> partnerLink they weren't supposed to use. Since I don't think
> any of us live in that world we need to give compensation
> handlers a way to protect their partnerLinks. An easy way to
> do that is to allow partnerLinks to be declared as scope
> local variables.
>
> Yaron
>
> > -----Original Message-----
> > From: Harvey Reed [mailto:]
> > Sent: Tuesday, October 21, 2003 10:53 AM
> > To:
> > Cc: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)'
> > Subject: RE: [wsbpel] Issue - 75 - Do we need locally declared
> > partnerLinks?
> >
> >
> > Yaron,
> >
> > I have extracted one of your key phrases:
> >
> > "...if a compensation handler is depending on the fact that the
> > endpoint reference for a partnerLink will have the same
> value when the
> > compensation handler runs as it did when the scope
> successfully exited
> > then the compensation handler can get into serious trouble..."
> >
> > Can you give a use case where an endpoint reference will
> change over
> > time, thus disabling the compensation handler?
> >
> > Thanks!
> > ++harvey
> >
> > -----Original Message-----
> > From: Yaron Goland [mailto:]
> > Sent: Tuesday, October 21, 2003 1:26 PM
> > To: Wsbpel@Lists. Oasis-Open. Org (E-mail)
> > Subject: [wsbpel] Issue - 75 - Do we need locally declared
> > partnerLinks?
> >
> > Executive Summary: In the examples below I show how the
> inability to
> > declare partnerLinks inside of scopes causes a lot of grief and
> > therefore propose that we allow partnerLinks to be declared
> as scope
> > local variables. But I suspect there was a good reason why
> > partnerLinks were restricted to only being declared
> globally, I just
> > don't remember what that reason is.
> >
> > Long Winded Version:
> >
> > My working assumption is that it will be very common for
> compensation
> > handlers to send and receive messages.
> >
> > The problem is that partnerLinks are only defined at the
> global scope.
> >
> > So, for example, if a compensation handler is depending on the fact
> > that the endpoint reference for a partnerLink will have the
> same value
> > when the compensation handler runs as it did when the scope
> > successfully exited then the compensation handler can get
> into serious
> > trouble as anyone, anywhere in the BPEL process who
> executes after the
> > scope successfully completes could change the value of the Endpoint
> > reference.
> >
> > In general the way to persist values so they will be available to
> > compensation handlers is to create a scope local variable that
> > persists the value that needs to be maintained. That scope local
> > variable is then persisted in the scope's context and available, in
> > its original form, when the compensation handler runs.
> >
> > Since partnerLinks can only be declared at a global scope it isn't
> > possible to store them in a scope local variable. The
> closest one can
> > get is to try and store the contents of the partnerLink into a
> > temporary variable and then restore the value when the compensation
> > handler is run. E.g.
> > something like:
> >
> > <assign>
> > <copy>
> > <from partnerLink="A"
> > endpointReference="partnerRole"/>
> > <to variable="StoreEndPointReference"/>
> > </copy>
> > <assign>
> >
> > A major problem with this approach is that BPEL does not define the
> > schema for an Endpoint reference (see issue 34) so there is
> no way to
> > know what XML schema type the StoreEndPointReference
> variable should
> > take.
> >
> > Assuming the BPEL TC decides to resolve this problem and define a
> > schema for endpointReferences there is also the problem of what the
> > semantics are for:
> >
> > <assign>
> > <copy>
> > <from variable="StoreEndPointReference"/>
> > <to partnerLink="A"/>
> > </copy>
> > <assign>
> >
> > For example, what if the original Endpoint reference pointed to a
> > specific HTTP connection that is no longer around? What fault is
> > supposed to be thrown? The key here is that assigning a value to a
> > partnerLink has side effects and those side effects need to
> be defined
> > and when problems ensue appropriate faults need to be defined.
> >
> > To make matters even more complicated it is quite possible
> that more
> > than one member of the BPEL process may be trying to use the
> > partnerLink at the same time as the compensation handler and the
> > competing code may have its own desired setting for the Endpoint
> > reference value for that partnerLink.
> > Because partnerLinks are global there is no good way to prevent
> > simultaneous access short of requiring every compensation
> handler to
> > be written inside of a serializable scope.
> >
> > Another approach is to require every compensation handler to define
> > its own unique partnerLink but this would cause an explosion of
> > partnerLinks at the start of the process whose only purpose
> would be
> > to work around the fact that partnerLinks can only be defined
> > globally. This would also get messy because if someone deletes or
> > somehow changes a compensation handler they have to remember to go
> > back and change the global
> > partnerLink(s) associated
> > with that compensation handler.
> >
> > A simple way around all of this mess is to allow partnerLinks to be
> > declared inside of scopes. I suspect there is a very good
> reason why
> > we don't allow this but I must admit I don't remember what it is.
> >
> > Thanks,
> > Yaron
> >
> >
>
>
> 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.
>
>
