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?


The basic assumption has been that the process' "listen points" are
deployment dependent and not dynamically changeable.  This applies to
myRole in any partnerLink.  But each link (as opposed to link type) can
have its own "listen point," i.e., EPR.

 
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Wednesday, November 12, 2003 3:47 PM
To: Frank Leymann
Cc: wsbpel@lists.oasis-open.org
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:    ygoland@bea.com
>cc:    "'Harvey Reed'" <hreed@sonicsoftware.com>, "'Wsbpel@Lists.
>       Oasis-Open. Org (E-mail)'" <wsbpel@lists.oasis-open.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: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_workg
roup.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_workg
roup.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_workgr
oup.php.
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
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.




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_workgr
oup.php.





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