[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] [Issue 52] CT generation (section 2.1.1) does nottake into consideration the multRefFrom attribute [Alternative proposal basedon Partner Link as multi-valued reference]
Few comments: 1) 2004.2 states -- [SBPEL2004.2] the name of the SCA reference MUST be determined by the name of the partner link (see section 2.3 for the algorithm that ensures that every introspected reference and service name are unique). This isn't correct. The PL may have both the multiRefFrom and reference attributes, in which case the name should be determined by the value of the reference attribute. I don't think we need 2004.2. If there is a reference attribute, 2003 already covers it, if not, then 2006 covers it. 2) Since exactly one PL points to a multi ref variable, what is the purpose of having the partnerRole and partnerLinkType attributes on multiReference element? Especially when the value is required to be the same as that of the PL that points to it. Documentation? I suggest removing it. 3) For 3011.1, I would like to suggest s/Only one/Exactly one/ 4) 3011 and the added word 'optional' after 3005 contradict each other. If we were to address the comment in (2) above, this of course goes away. 5)3005.11 talks about exception being thrown. In the SCA specs we talk about generating an error not exceptions. There is a bigger issue here, that we don't say much about when the SCA BPEL runtime must generate an error (similar to what the other SCA specs say) -- but this is a separate issue. For example, what should happen if a non-coformant SCA WS-BPEL document is involved in a contribution/deployment. -Anish -- Najeeb Andrabi wrote: > 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: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/ > > > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]