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 concur. Allowing partner links to be declared locally to a scope would 
tremendeously simplify the use of BPEL in those case where a partner 
link is used with more than one partner (loops, event handlers, even two 
activities executed in order).


Yaron Goland wrote:

>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
>>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
>>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?
>>-----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
>>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"
>>			<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
>>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/leave_workgroup.php.

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