RE: [wsbpel] Issue - 75 - Do we need locally declared partnerLinks?

["Edwin Khodabakchian" <edwink@collaxa.com>]

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:ygoland@bea.com] 
> 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: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
> >
> >
> 
> 
> 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.
> 
>