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:mike_edwards@uk.ibm.com]
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: mike_edwards@uk.ibm.com
From:
|
Michael Rowley <michael.rowley@activevos.com>
|
To:
|
Najeeb Andrabi <nandrabi@tibco.com>, OASIS BPEL
<sca-bpel@lists.oasis-open.org>
|
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: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
---------------------------------------------------------------------
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