[sca-bpel] [Issue 52] CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute [Alternative proposal based on Partner Link as multi-valued reference]

I have updated the proposal for issue 52 to include
the changes that we agreed on:

1)   Multi-valued reference name is derived from the partner
link (SBPEL2004.1,SBPEL2004.2).

2)   Constraint specifying that only one partner link with @multiRefForm
attribute can refer a variable with mutliReference extension (SBPEL3011.1).

3)   Exception handling for the case where a variable with multiReference
extension is declared but none of the partner links has a reference to it
(SBPEL 3005.1)

4)   Initialization mechanism for variables with multiReference
extension.

 

--Najeeb

 

 

From: Najeeb Andrabi
[mailto:] 

Sent: Monday, August 31, 2009
10:23 AM

To: Mike Edwards; OASIS BPEL

Subject: RE: [sca-bpel] [Issue 52]
CT generation (section 2.1.1) does not take into consideration the multRefFrom
attribute [Alternative proposal based on Partner Link as multi-valued
reference]

 

My understanding is that partner link declaration and its
EPR initialization has nothing to do with a particular structured activity. In
my view the only constraint for multi-valued partner link declaration is that
the variable referred by @mutliRefForm attribute must be in its scope (Issue
56). Other than that partner link must follow the standard BPEL 2.0 lifecycle
rules.

 

--Najeeb

 

From: Mike Edwards
[mailto:] 

Sent: Monday, August 31, 2009
12:24 AM

To: OASIS BPEL

Subject: RE: [sca-bpel] [Issue 52]
CT generation (section 2.1.1) does not take into consideration the multRefFrom
attribute [Alternative proposal based on Partner Link as multi-valued
reference]

 

Folks, 

Perhaps
I've missed something here, but I don't follow the two points that Michael
Rowley makes - I'd appreciate it if someone could explain in more detail.

Regarding
the concept of a multi-valued reference that is manipulated by more than one
forEach - I see no problem if the variable and the partnerLink are

declared
at the global level.  Is the point here really about nested forEach
statements where there is a need for redeclaration of  the partnerLink at
each 

nesting
level?  If this is the case, then I'd like to ask about the directly
parallel case of a 1..1 reference used within nested forEach - how is that
supposed 

to
work? 

As for
the second case, I simply don't understand.  How does the processing of
the partnerLink affect its declaration?  The declaration is static and is
either 

present
or not present - usage makes no difference to this. 

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley
Park, Mail Point 146, Winchester, SO21
  2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:   

 

  
  
From: 

  
  
  
Michael Rowley <>
  

  
 

 

  
  
To: 

  
  
  
Najeeb Andrabi <>, OASIS BPEL
  <> 

  
 

 

  
  
Date: 

  
  
  
28/08/2009 17:09 

  
 

 

  
  
Subject:
  

  
  
  
RE: [sca-bpel] [Issue 52] CT generation (section 2.1.1)
  does not take into consideration the multRefFrom attribute [Alternative
  proposal based on Partner Link as multi-valued reference]

  
 

 

This is certainly a viable approach.  I'd say
there are two additional disadvantages:

- It is impossible to have one multi-valued
references that is manipulated by more than one for-each.  Recall that the
for-each deals with the multi-valued reference by declaring a locally scoped
partner link.

- It is impossible to have a multi-valued reference
that, perhaps temporarily, is not processed by any for-each (i.e. it has no
locally scoped partner links that refer to it).

Michael

-----Original Message-----

From: Najeeb Andrabi [mailto:] 

Sent: Wednesday, August 26, 2009 3:25 PM

To: OASIS BPEL

Subject: [sca-bpel] [Issue 52] CT generation
(section 2.1.1) does not take into consideration the multRefFrom attribute
[Alternative proposal based on Partner Link as multi-valued reference]

I have created an alternative proposal based on
arguments that I made in support of the partner link representing a
multi-valued reference instead of a variable.

The pros for partner link representing a
multi-valued reference are as

follows:

1) BPEL process interfaces with external systems
using partner links.

Since multi-valued reference is just a special
case of single reference, its declaration must follow the same paradigm.

2) SCA-BPEL specification uses partner links to
determine what constitutes a service or a reference. Why should a multi-valued
reference be determined by an alternative mechanism?

3) BPEL variables are meant for holding
meta-data/state of the process not for defining external interfaces.

Cons for using a partner link to represent multi-valued
reference are as

follows:

1) It breaks backwards compatibility, as SCA-BPEL
1.0 uses a variable to represent multi-valued reference.

2) There is an extra level of indirection as
partner link refers to a variable that in-turn holds the meta-data for
multi-valued reference.

Changes:

Section 2.1.1: I have added [SBPEL2004.1] and
[SBPEL2004.2] based on the original proposal sent by Anish.

Section 3.2: The partner link having
"sca-bpel:multiRefForm" attribute is manifested as a multi-valued
reference instead of a variable having "sca-bpel:multiReference"
child element. Made partnerLinkType and partnerRole attributes of
"sca:bpel:multiReference" element optional.

--Najeeb

            

-----Original Message-----

From: Anish Karmarkar [mailto:]

Sent: Wednesday, August 19, 2009 11:16 PM

Cc: OASIS BPEL

Subject: Re: [sca-bpel] [Issue 52] CT generation
(section 2.1.1) does not take into consideration the multRefFrom attribute --
Version 2

Version 2 based on last week's comments.

Attached.

The only change is in SBPEL2010.

-Anish

--

Anish Karmarkar wrote:

> Spec with inlined proposed amendment, listed
by Michael (below),

attached.

> 

> -Anish

> --

> 

> Michael Rowley wrote:

>>  

>>

>> Proposal amendment: Change 2.1.1 so that
any partner link with 

>> MultiRefFrom attribute is not made into a
service or reference and

the 

>> partner link must not include a
sca:reference or sca:service

annotation.

>>

>>  

>>

>> Also the <multireference> element
should also include a name

attribute 

>> so that people can customize the
reference name that is generated.

>>

>>  

>>

>> Michael

>>

>>  

>>

>>  

>>

>> *From:* Michael Rowley

>> *Sent:* Thursday, July 23, 2009 1:48 PM

>> *To:* Michael Rowley; Danny van der Rijn

>> *Cc:* Anish Karmarkar; OASIS BPEL

>> *Subject:* RE: [sca-bpel] [Issue 52] CT
generation (section 2.1.1) 

>> does not take into consideration the
multRefFrom attribute

>>

>>  

>>

>>  

>>

>> This time with attachment.

>>

>>  

>>

>> *From:* Michael Rowley

>> *Sent:* Thursday, July 23, 2009 1:47 PM

>> *To:* 'Danny van der Rijn'

>> *Cc:* Anish Karmarkar; OASIS BPEL

>> *Subject:* RE: [sca-bpel] [Issue 52] CT
generation (section 2.1.1) 

>> does not take into consideration the multRefFrom
attribute

>>

>>  

>>

>>  

>>

>> Sure.  Here is a marked up spec.

>>

>>  

>>

>> Michael

>>

>>  

>>

>> *From:* Danny van der Rijn [mailto:]

>> *Sent:* Thursday, July 23, 2009 1:14 PM

>> *To:* Michael Rowley

>> *Cc:* Anish Karmarkar; OASIS BPEL

>> *Subject:* Re: [sca-bpel] [Issue 52] CT
generation (section 2.1.1) 

>> does not take into consideration the
multRefFrom attribute

>>

>>  

>>

>> I'm having trouble shuffling this all
around in my head.  If it's not

>> too much trouble could you either include
context-diff-like text or a

>> marked up spec doc?

>>

>> Fuzzily yours,

>> Danny

>>

>> Michael Rowley wrote:

>>

>>  

>>

>> Alternative proposal:

>>

>> Move requirements 3006 and 3007 to the end
of section 2.1.1 (and 

>> possibly renumber the requirements).

>>

>> In the place where those requirements
used to exist, insert the text:

>> "The introspected component type
will include a reference with 

>> multiplicity 0..n for this variable, as
specified in section 2.1.1."

>>

>> Michael

>>

>> -----Original Message-----

>> From: Anish Karmarkar [mailto:]

>> Sent: Wednesday, July 15, 2009 8:11 PM

>> To: OASIS BPEL

>> Subject: [sca-bpel] [Issue 52] CT
generation (section 2.1.1) does not

>> take into consideration the multRefFrom
attribute

>>

>> This is now issue 52

>> http://osoa.org/jira/browse/BPEL-52

>>

>> Anish Karmarkar wrote:

>>>  Title: CT generation (section
2.1.1) does not take into

consideration

>>>  the multRefFrom attribute

>>>

>>>  Target: BPEL C&I spec

>>>

>>>  Description:

>>>  If a partnerLink does not
contain a sca-bpel:reference or a  

>>> sca-bpel:service attribute, the
algorithm in section 2.1.1

Generating

>>>  Services and References
requires doing a static analysis

(SBPEL2005) to

>>>  figure out if the PL should be
mapped to a sca reference or a

service.

>>>  It does not give any consideration
to the sca-bpel:multiRefFrom  

>>> attribute that may be present on the
PL.

>>>

>>>  A PL with such a attribute
should be mapped to an SCA reference and  

>>> never to a SCA service.

>>>

>>>  Proposal:

>>>

>>>  Add two new requirement (after SBPEL2004):

>>>  [SBPEL2004.1] If a partner link
specifies a sca-bpel:multiRefFrom  

>>> attribute, then a reference MUST be
generated for the introspected  

>>> component type. [SBPEL2004.2] If the
name of the partner link is

unique

>>>  within the process, then it
MUST be used as the name of the

reference.

>>>  Otherwise, the name is
determined according to the rules of section

>>> 2.3.

>>>

>>>  Modify SBPEL2005 as follows:

>>>  s/If neither sca-bpel:service
nor sca-bpel:reference is present/If

none

>>>  of the attributes:
sca-bpel:service, sca-bpel:reference or  

>>> sca-bpel:multiRefFrom is present/

>>>

>>>  Modify SBPEL2007 to include the
two new requirements.

>>>

>>>  -Anish

>>>  --

>>>

>>>

---------------------------------------------------------------------

>>>  To unsubscribe from this mail
list, you must leave the OASIS TC

that

>>>  generates this mail.
 Follow this link to all your TCs in OASIS at:

>>>

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>>

>>
---------------------------------------------------------------------

>> To unsubscribe from this mail list, you
must leave the OASIS TC that 

>> generates this mail.  Follow this link
to all your TCs in OASIS at:

>>

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>>

>>

>>
---------------------------------------------------------------------

>> To unsubscribe from this mail list, you
must leave the OASIS TC that 

>> generates this mail.  Follow this
link to all your TCs in OASIS at:

>>

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>>

> 

>

------------------------------------------------------------------------

> 

>
---------------------------------------------------------------------

> To unsubscribe from this mail list, you must
leave the OASIS TC that 

> generates this mail.  Follow this link
to all your TCs in OASIS at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave
the OASIS TC that

generates this mail.  Follow this link to all
your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

 

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England
and Wales
with number 741598. 

Registered office: PO Box 41,
  North Harbour, Portsmouth, Hampshire PO6 3AU

sca-bpel-1 1-spec-cd02-rev2+issue52-na-rev2.doc