Next in thread →
Next in month →
RE: [sca-bpel] [Issue 52] CT generation (section 2.1.1) does not take intoconsideration the multRefFrom attribute [Alternative proposal based onPartner 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
Next in thread →
Next in month →