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

[Michael Rowley <michael.rowley@activevos.com>]

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:nandrabi@tibco.com] 
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:Anish.Karmarkar@oracle.com]
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:dannyv@tibco.com]
>> *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:Anish.Karmarkar@oracle.com]
>> 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