I have made following changes to attached spec based
on the things we agreed on in the last call (Sept 3rd):
1) Deleted [SBPEL2004.2]
2) Deleted [SBPEL3011]; changed [SBPEL3011.1] to
[SBPEL3011] based on the text provided by Mike Edwards regarding
multi-reference variable referenced
only by one and only one partner link.
3) Removed partnerLinkType and partnerRole attributes for
multiReference child element.
4) Deleted example for initialization of variable with
multiReference extension.
5) Updated picture of the multi-valued reference example
provided in section 3.2.
--Najeeb
From: Najeeb Andrabi
[mailto:nandrabi@tibco.com]
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: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