[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
I think there are still some problems with the introspection algorithm: 1) Section 3.2 says: "When this sca-bpel:multiRefFrom extension is applied to pair up a multi-valued reference variable and a partner link which is categorized as the “References” case 1 (as described in section 2.12.1), the partner link and variable are manifested as a single multi-valued reference entity in SCA assembly model using the name of the variable." But if I use the algorithm in section 2.1.1, I end up with two references one for the partnerLink and one for the multi-valued reference variable, even if the partnerLink has multiRefFrom attribute. 2) There is nothing that disallows a partnerLink that has multiRefFrom attribute from being mapped to a service in SCA (if the conditions of SBPEL2005 are satisfied). 3) It is possible for a multi-valued reference var to exist without any partnerLink pointing to it via multiRefFrom. What use case does this serve? 4) It is possible for a multi-valued reference var to exist with multiple partnerLinks pointing to it via multiRefFrom. What use case does this serve and how would the CT mapping take place if the intention was to surface the PL and multi-valued variable as a single SCA reference? I'm wondering if we should require that every multi-valued var be referenced by exactly one PL through the multiRefFrom attribute and such a multi-valued var/PL pair be exposed as a multi-valued SCA reference in the introspected CT. -Anish -- Michael Rowley wrote: > > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]