[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference fora partnerLink declared with multiRefFrom extension
Yes, it is true. Dieter's formulation disallows reference and multiRefFrom attribute from co-occurring, which should be allowed. And your formulation allows service and reference attributes to co-occur, which is not allowed. What we talked about on the call was doing the following: 1) if ignore is present then disallow any other extension attribute 2) make service/reference attributes mutually exclusive 3) make service/multiRefFrom attributes mutually exclusive I think it would be simplest to have two labeled normative stmts to cover this instead of trying to fit it in one stmt. But, I'm wondering if we really need (1) above. If ignore is present, why does it matter what else is there? Ignore says, skip this PL as far as SCA introspection is concerned. In such cases, the SCA runtime shouldn't have to check what else is there on the PL. This can be useful during the dev/testing phase where you have a reference/multiRefFrom/service attribute on a PL and you want to hide that from SCA for a particular test run. In such a case it is just easy to stick an ignore attribute on the PL without changing anything. Restoring the PL back requires just deleting the ignore attribute. One other comment on the proposal: s/sca-bpel:ignore attribute with a value of ‘true’/sca-bpel:ignore attribute with a canonical value of ‘true’/ Thoughts? -Anish -- On 8/20/2010 9:23 AM, Patil, Sanjay wrote: > > AFAIU, we do allow the combination of sca-bpel:reference and sca-bpel:multiRefFrom attributes. Is that not true? > > -----Original Message----- > From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] > Sent: Friday, August 20, 2010 1:16 AM > To: Patil, Sanjay > Cc: sca-bpel@lists.oasis-open.org > Subject: RE: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference for a partnerLink declared with multiRefFrom extension > > Sanjay, for SBPEL3020, we shoudld not lose the restriction that makes the > SCA attributes mutually exclusive with each other, so IMO it is better to > just extend the existing sentence. > > Old: > [SBPEL3020] A process MUST NOT include more than one of sca-bpel:ignore, > sca-bpel:service and sca-bpel:reference attributes on a single partner > link. > New: > [SBPEL3020] A process MUST NOT include more than one of sca-bpel:ignore, > sca-bpel:service, sca-bpel:reference and sca-bpel:multiRefFrom attributes > on a single partner link. > > Kind Regards > > Dieter Koenig > > Senior Technical Staff Member, WebSphere BPM Architecture, Standardization, > Integration Quality Assurance > IBM Software Group, Application and Integration Middleware Software > WSS Business Process Solutions > > > > > > Phone: +49-7031-16-3426 IBM Deutschland (Embedded > image moved > to file: > pic20482.gif) > > E-Mail: dieterkoenig@de.ibm.com Schönaicher Str. 220 > > 71032 Böblingen > > Germany > > > > > > IBM Deutschland > Research& > Development > GmbH / > Vorsitzender des > Aufsichtsrats: > Martin Jetter > Geschäftsführung: > Dirk Wittkopp > Sitz der > Gesellschaft: > Böblingen / > Registergericht: > Amtsgericht > Stuttgart, HRB > 243294 > > > > > > > From: "Patil, Sanjay"<sanjay.patil@sap.com> > To: "sca-bpel@lists.oasis-open.org"<sca-bpel@lists.oasis-open.org> > Date: 19.08.2010 19:39 > Subject: RE: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference > for a partnerLink declared with multiRefFrom extension > > > > Attached is the CD2Rev9 document along with the proposed changes for > resolving the Issue 64. > > The proposed changes are in sections 3.2.1 and 3.3, which I am also > including here for your convenience: > > 2.3.1 Algorithm for Generating Unique SCA Service and Reference Names > Algorithm: > Let S be the set of names of SCA services and references generated > from introspecting the BPEL process definition as defined in > section 2.1.1, at any given point in time. > At the start of the introspection, S is empty. > The BPEL process is examined in lexical order for occurrences of > partnerLinks and multi-valued variableswhich do not have the > sca-bpel:ignore attribute with a value of ‘true’. > For each partnerLink or multi-valued variable that is encountered: > If the sca-bpel:service or sca-bpel:reference attribute is > present on the partnerLink, its value MUST NOT be a member > of S. The value of the attribute is added to S and an SCA > service or reference added to the componentType of the BPEL > process as defined in section 2.1.1. > Else if the name attribute is present on the > sca-bpel:multiReference extension element of a variable, its > value MUST NOT be a member of S. The value of the attribute > is added to S and an SCA reference is added to the > componentType of the BPEL process as defined in section > 2.1.1. > Else if the name of the partnerLink is not a member of S, > then the name is added to S and an SCA service or reference > is added to the componentType of the BPEL process as defined > in section 2.1.1. > Else if the name of the partnerLink is already present in S, > the name is prefixed and suffixed with the "_" character. In > addition, the name is also suffixed with additional > characters that represent the smallest positive integer > without any leading zero(s), which results in a name that > does not conflict with any existing member of S. The > resulting name is added to S an SCA service or reference is > added to the componentType of the BPEL process as defined in > section 2.1.1. > > > 3. Partner Link Mapping to Services and References > …. > > [SBPEL3020] A process MUST NOT include more than one of sca-bpel:ignore, > sca-bpel:service and sca-bpel:reference attributes on a single partner > link. A partnerLink MUST NOT have the sca-bpel:ignore attribute when an > sca-bpel:service or an sca-bpel:reference or an sca-bpel:multiRefFrom > attribute is also present on that partnerLink. > > Thanks, > Sanjay > > -----Original Message----- > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > Sent: Wednesday, August 18, 2010 11:54 PM > To: sca-bpel@lists.oasis-open.org > Subject: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference for a > partnerLink declared with multiRefFrom extension > > This is issue 64. > http://osoa.org/jira/browse/BPEL-64 > > -Anish > -- > > On 8/18/2010 10:14 AM, Patil, Sanjay wrote: >> Title: Name of the generated SCA reference for a partnerLink declared >> with multiRefFrom extension >> Target: SCA WS-BPEL C&I Specification Version 1.1 CD 2 Rev 9 >> Description: >> There is no normative statement in the specification for generating name >> of an SCA reference which corresponds to a partnerLink that uses the >> multiRefFrom extension. >> There is discrepancy in how the name of a reference is generated for a >> partnerLink with multiRefFrom extension: >> >> * Section 2.3.1 uses the name of the variable with multiReference >> extension as the name of the generated reference. See the text: >> ‘Else if the name attribute is present on the >> sca-bpel:multiReference extension …’ >> * Section 3.2 uses the name of the partnerLink as the name of the >> generated reference. See the text at the bottom of the section: ‘A >> multi-value reference named “vendorLink” , which his categorized as > …” >> >> Proposal: >> Add a normative statement after the SBPEL2024 statement: The name of the >> reference MUST be the value of the name attribute of the partnerLink. >> Update the sections 2.3.1 and 3.2 to comply with the added normative >> statement. > > --------------------------------------------------------------------- > 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 > > [attachment "sca-bpel-1.1-spec-cd02-rev9-issue64.doc" deleted by Dieter > Koenig1/Germany/IBM] > --------------------------------------------------------------------- > 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]