Re: [sca-bpel] BPEL Process: References with Multiplicity 0..1 -how are they supposed to work? *PLEASE DISCUSS*

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

I was hoping for the BPEL 2.0 experts to chime in. But since one one 
has, here are my non-expert comments:

If initializePartnerLink="no" is specified, then the process, I assume, 
has a way to figure out the EPR. Otherwise the attribute should have 
been set with a value of 'yes'

But I do think there is a related issue. If initializeParnerLink="no" 
then per BPEL 2.0 spec, as you point out, the processor MUST NOT 
initialize the EPR. But for certain cases (1st use by any activity is 
not in <assign>) this gets mapped in SCA to a reference with 
multiplicity of 0..1. If the SCA composite leaves this unwired this 
isn't a problem. But if it does wire it, what happens then? SCA will 
provide the value for the PL but the process definition says it should 
not be.

-Anish
--

Mike Edwards wrote:
> 
> Folks,
> 
> Being engaged in implementing the BPEL version of the Assembly test 
> suite, gives me first-hand grappling
> experience with the nuances of the SCA BPEL C & I spec.
> 
> One topic that has entertained me recently is the implementation of 
> multiplicity 0..1 references and I'd like to
> discuss these in this email - with the possibility that we shall need an 
> issue to change the SCA BPEL spec in
> a number of places.
> 
> 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.
> 
> 
> What I have done so far in the BPEL version of the Assembly spec is 
> along the following lines:
> 
> - the code always supplies an initializer value for any 0..1 
> multiplicity partnerLink
> - however, in the case of an unwired reference, the initializer value 
> consists of the following alone:
> 
> <sref:service-ref/>
> 
> - for a wired reference, the initializer value consists of the following:
> 
> <sref:service-ref><EPR ...../><sref:service-ref>
> 
> - the EPR element contains some (opaque) information about the target 
> endpoint
> 
> The BPEL process then is able to test the value of the partnerLink (by 
> copying to a variable typed as an sref:service-ref element),
> basically looking to see if the <sref:service-ref/> element has any 
> child elements or not - if there are none, then the reference
> is unwired.
> 
> Note that this assumes the following:
> a) @initializePartnerRole="no" has *NOT* been specified
> b) the BPEL processor DOES initialize a partnerLink for which 
> @intiializePartnerRole has not been specified  (ODE, the engine
> I'm using at the moment, does do this)
> 
> 
> 
> However, I'm not at all sure that this is the route that we should take 
> in the spec for the long term.  I am convinced that we shall
> have to change the spec to some extent, however.
> 
> 
> DISCUSSION WELCOME !!!
> 
> 
> 
> 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/
> 
> 
> 
> 
> 
>