← Prev in month
← Prev in thread
Re: [sca-bpel] [Issue 53] BPEL Process: References with Multiplicity0..1 - how are they supposed to work?
I found more problems with that section: The 1st bullet in (Multi-Reference) is wrong. It says - Multi-Reference. [SBPEL2010] If the partner link is declared with an sca-bpel:multiRefFrom="aVariableName" extension, the multiplicity of the SCA reference MUST be determined by the multiplicity attribute of sca-bpel:multiReference extension used in the corresponding variable. Details of these extensions are described in section REF _Ref132690776 \r \h 3.2. It is not the the partnerLink that determines this, it is the variable. It should instead say: Multi-Reference. [SBPEL2010] If the variable is declared with an sca-bpel:multiReference extension, the multiplicity of the SCA reference MUST be determined by the multiplicity attribute of sca-bpel:multiReference extension. Details of these extensions are described in section 3.2 This is one of the reasons I thought it was the partnerLink with multiRefFrom that was exposed as a reference and not the variable, hence my initial proposal for issue 52 was crafted the way it was. -Anish -- Michael Rowley wrote: Proposal: Change the sentences in section 2.1.1 which currently reads: 3. Stub Reference. [SBPEL2012] If neither [SBPEL2010] nor [SBPEL2011] apply and the analysis of the process determines that the first use of the partner link by any activity is in an <assign> activity that sets the partner role, then the multiplicity MUST be "0..1" and the attribute wiredByImpl MUST be set to "true". to instead read: 3. Stub Reference. [SBPEL2012] If [SBPEL2010] does not apply and the partner link has initializePartnerRole="no", then the multiplicity MUST be "0..1" and the attribute wiredByImpl MUST be set to "true". Note that (4), which follows this, will turn any other partnerLink into a reference with multiplicity of 0..1 (not wiredByImpl). Michael -----Original Message----- From: Anish Karmarkar [mailto:] Sent: Thursday, August 06, 2009 3:39 PM To: OASIS BPEL Subject: [sca-bpel] [Issue 53] BPEL Process: References with Multiplicity 0..1 - how are they supposed to work? This is now issue 53 http://osoa.org/jira/browse/BPEL-53 Mike Edwards wrote: > > Raiser: Mike Edwards > > Target: > > Description: > > > Multi-valued references (ie 0..n and 1..n) are discussed in the > specification at some length, particularly in section > 3.2. Unfortunately, the case of 0..1 references is mentioned only in > passing, although it has some significant > matters that need discussion and clarification. > > Section 2.1.1 makes it clear that 0..1 multiplicity references do exist > for BPEL processes. > > Basically, it states that where a partnerLink is determined to be a > reference, it will be 0..1 if @initializePartnerRole="no" > OR @initializePartnerRole is omitted. It must also be the case that the > partnerLink must not have its "first use" as the > target of an <assign/> operation. > > Now, reading the BPEL 2.0 specification: > > @initializePartnerRole="no" means that the BPEL Processor MUST NOT > initialize the partnerLink variable. > > @initializePartnerRole omitted means that the BPEL Processor MAY > initialize the partnerLink variable. > > > Now, the problems are these: > > A) If the partnerLink is NOT initialized, then it is essential that it > is initialized by the BPEL process itself, since any > attempt to use that partnerLink variable will otherwise result in a fault. > > So, if the partnerLink is marked @initializePartnerRole="no", the > partnerLink must be supplied with a value - but > how is such a value supplied to the BPEL process by SCA? The SCA BPEL > spec talks about the way in which > serviceReferences are supplied in a variable typed as a > serviceReferenceList for multi-valued references. > There is no such equivalent for 0..1 references. > > Even if the partnerLink is not marked with @initializePartnerRole at > all, it is STILL possible for the partnerLink to > be uninitialized and so unusable without being assigned a value by the > BPEL process - this is the result of that > "MAY" in the BPEL 2.0 spec, listed above. Again, there is no means by > which the BPEL process can get a > serviceReference to assign into the partnerLink. > > > B) If the partnerLink IS initialized, how can the BPEL process determine > the difference between the case where the > reference is wired and the case where the reference is unwired? > > There is no standard means for doing this in BPEL. > > So, I think we may have a problem with 0..1 references in the SCA BPEL > spec. > > Proposal: > > None > > > 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: > > > ------------------------------------------------------------------------ > > / > / > > /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
← Prev in month
← Prev in thread