OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-bpel] [Issue 53] BPEL Process: References withMultiplicity 0..1 - how are they supposed to work?


 

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:Anish.Karmarkar@oracle.com]
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:  mike_edwards@uk.ibm.com

>

>

> ------------------------------------------------------------------------

>

> /

> /

>

> /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]