[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?
Frank Leymann wrote: >My strong tendency is to object! > >I absolutely do not ignor the power of locally scoped partner links in case >of highly dynamic business processes and dynamically assigned partner >endpoints (e.g. in a loop), but this will make BPEL much more complex to >comprehend. > >Partner links are those BPEL artifacts which are the targets of deployment. >BPEL itself is deployment agnostic. In order to put a valid process model >into production, i.e. to make it operational, one has to bind/deploy the >port types specified in the various partner links. What does it mean to >bind/deploy a partner link within a scope of a while-loop? In practice it >will end up using EPRs dynamically assigned to roles. But this can be done >already today. > > To make partner links work within a scope that may be initialized multiple times (loop, event handler) and refer to a different partner in each initialization, and allow the associated compensation handler to reference the same partner as used during the scope's execution, you need to use a variable and assign the partner link to/from that variable. >From a syntax perspective this is very simple, but unfortunately, unless you add all the necessary assignements, it would not happen automatically. In practice we'll see people getting it wrong the first time before they wrap their minds around the need to do explicit variable management. Especially since everything else (variables, nested scopes, correlation sets, event handlers) is already localized to the scope, and only partner links operate differently. >More questions arise, like: Is only one role of a partner link locally >scoped? For example, if myRole doesn't change but only the partner role >does change...? > To answer this question I first need to understand the thinking behind the current use of EPRs. Let's say a process declares two partner links based on the same partner link type, e.g. in order to concurrently converse with two parnters of the same type. Are their myRole EPR's equivalent? arkin >Regards, >Frank > >------------------- >Prof. Dr. Frank Leymann, Distinguished Engineer >IBM Software Group >Member, IBM Academy of Technology > >Phone 1: +49-7031-16 39 98 >Phone 2: +49-7056-96 50 67 >Mobile: +49-172-731 5858 >-------------------- > > > > > >To: firstname.lastname@example.org >cc: "'Harvey Reed'" <email@example.com>, "'Wsbpel@Lists. > Oasis-Open. Org (E-mail)'" <firstname.lastname@example.org> >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:email@example.com] >>>Sent: Tuesday, October 21, 2003 10:53 AM >>>To: firstname.lastname@example.org >>>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:email@example.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 >. > > >> >> > > > > >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 >. > > > > > > > >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. > > -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin firstname.lastname@example.org Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]