RE: [wsbpel] Issue - 75 - Do we need locally declared partnerLinks?

["Yaron Goland" <ygoland@bea.com>]

If I understand the points made on this thread correctly then there are two
questions that have to be answered if we are to support locally scoped
partnerLinks.
	#1 - How do you specify myRole for dynamically specified
partnerLinks?
	#2 - How do you specify partnerRole for dynamically specified
partnerLinks?

Dealing with #1 at deployment time is relatively straight forward. The BPEL
has no say as to what EPR is used in myRole. So a BPEL engine can choose
whatever deployment behavior it would like. It can require that one EPR be
used for every myRole in every partnerLink in the process (after all,
portType in an EPR is optional). It can dynamically generate EPRs. It can
statically generate EPRs for the same portType and re-use them for dynamic
myRoles, whatever. The BPEL process doesn't need to know since it has no say
in the choice.

#2 however brings up an interesting question. Today, how does a BPEL process
know when the EPR for the partnerRole in a partnerLink will be statically
configured at deploy time and when the BPEL process itself is expected to
define the EPR for the partnerRole using <assign>? The answer is - it
doesn't.

This seems like a bug to me. It seems to me that there should be an
attribute defined on a partnerLink definition whose meaning is 'I, the BPEL
process, expect the BPEL engine to define the EPR for the partnerRole for
this partnerLink for me.' This would make it clear to the BPEL programmer
what partnerRoles they are required to configure using <assign> and which
partnerRoles they can count on the BPEL engine to provide an EPR for.

E.g.
<partnerLink deployDefined="yes">
   ...
</partnerLink>

The previous point now leads me to issue #2. I would only allow the
deployDefined attribute on globally defined partnerLinks. The assumption
being that the EPR for a locally scoped partnerLink's partnerRole must be
defined by the BPEL process using an <assign>.

	Make Sense?

		Yaron

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Monday, November 17, 2003 8:57 AM
> To: Assaf Arkin
> Cc: Frank Leymann; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 75 - Do we need locally declared
> partnerLinks?
> 
> 
> I would not want to make myRole dynamic - dynamic (visible) listen
> points will take us in the direction of auto generation. This is the
> complication - copies of partnerLinks that need to stay consistent for
> myRole and dynamic for partnerRole. 
> 
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com] 
> Sent: Monday, November 17, 2003 7:37 AM
> To: Satish Thatte
> Cc: Frank Leymann; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 75 - Do we need locally declared
> partnerLinks?
> 
> Satish Thatte wrote:
> 
> >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.
> >  
> >
> Then let's try and tackle it.
> 
> The spec already has to deal with lifetime semantics of 
> locally scoped 
> variables and correlation sets. Let's assume that partner links are 
> another type of scoped variable accessed (read/write) like any other 
> locally or globally declared variable. That would cover the 
> lifetime and
> 
> access semantics. The spec also handles the case where 
> multiple partner 
> links are based on the same partner link type. We can extend 
> that to the
> 
> myRole EPR of a locally declared partner link (i.e. unique 
> EPR in each 
> scope).
> 
> What other problems are we going to run into?
> 
> arkin
> 
> >Satish
> >  
> >
> 
> 
> 
> 
> 
> 
> 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/le
> ave_workgroup.php.
> 
>

<<attachment: winmail.dat>>