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: 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:hreed@sonicsoftware.com]
> Sent: Tuesday, October 21, 2003 10:53 AM
> To: ygoland@bea.com
> 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:ygoland@bea.com]
> 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
>
>



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