[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). arkin 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 >>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/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]