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?


Assaf, if the issue was partnerLink visibility limited to a local scope
it would be trivial.  But that is the only situation where you can have
'each locally scoped partner link is assigned a unique endpoint
reference'.  All the examples I have seen justifying this idea also
require lifetime semantics, i.e., multiple copies of a locally scoped
partnerLink could exist, held, e.g., in corresponding compensation
handlers.  Now the situation becomes much more complex as Frank pointed
out earlier.

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Friday, November 14, 2003 12:57 PM
To: Assaf Arkin
Cc: Frank Leymann; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 75 - Do we need locally declared
partnerLinks?

Sorry, minor confusion here. EPR is not the end-point address as defined

by WSDL, but rather a WS-Address, if I understand it correctly, so we 
can have two EPRs with the same end-point address but different 
property. Do I understand that correctly?

My answer was strictly thinking on the end-point address itself. 
Rethinking about it in the context of WS-Address, I still think we 
should answer it with 'each locally scoped partner link is assigned a 
unique endpoint reference'.  Let the implementation determine how to 
deal with that.

arkin

Assaf Arkin wrote:

> Frank Leymann wrote:
>
>> Arkin,
>>
>> here is a quote from [BPEL 1.1 ? section 7.4]:
>>
>>      "? Every partner role in a partnerLink in a BPEL4WS process 
>> instance
>>      is assigned a unique endpoint reference in the course of the
>>      deployment of the process or dynamically by an activity within
the
>>      process. ? "
>>
>>  
>>
> Does this sentence refer specifically to partnerRole EPR or to both 
> partnerRole and myRole EPR?
>
> The way I understand this sentence is as follows. The answer to the 
> question 'given two partner links defined based on the same partner 
> link type, would they have the same EPR' could be:
>
> a) yes
> b) no
> c) maybe (a or b, implementation deteremined)
>
> And BPEL currently picks c). It's 'unique' which means it may well be 
> 'unique and different' (yes) or 'unique and equal' (no) or any 
> combination across or within the same implementation.
>
>
> The original question was:
>
> 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...?
>
> I would suggest that we tackle is the same way. In other words, 'each 
> locally scoped partner link is assigned a unique endpoint reference'.
>
> Is that something we can work with?
>
> arkin
>
>
>
>> The mental model behind this is that during deployment each role
(myRole
>> and partnerRole - if applicable) will get an EPR assigned; EPR is
meant
>> "conceptually" up to now: Since deployment itself is out of scope of 
>> BPEL,
>> the concrete format/syntax assigned to a role during deployment is
not
>> defined in BPEL at all. And if deployment information is never 
>> communicated
>> in messages there is no need to represent it syntactically as an EPR;

>> but
>> it helps comprehension to think of each role within a partner link
being
>> associated with an EPR. If your process needs to participate in
>> communication about this deployment information it has to be rendered
as
>> EPR.
>>
>> BPEL further allows that multiple partner links can have the same 
>> partner
>> link type. Thus, it is allowed that the same role in different
partner
>> links has different EPRs assigned, i.e. is deployed differently. And,
of
>> course, the EPR of a partnerRole in a given partner link may change
over
>> time based on appropriate use of assignments.
>>
>> As a consequence, "deployment of roles" is not static.  Especially,
it
>> means that the endpoint associated with a role within a partner link 
>> can be
>> bound as late as when using the partner link the first time. But once

>> it is
>> bound it is fixed within the process instance with the exception that
>> partnerRole of a partnerLink can be set for the instance via assign.
>>
>>
>> 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:    Frank Leymann/Germany/IBM@IBMDE
>> 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_workgr
oup.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 
>>>
>>>   
>>
>>
>>  
>>
>>> .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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 
>>
>> .
>>
>>
>>
>>
>>
>>
>>
>> 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]