[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] BPEL Process: References with Multiplicity 0..1 -how are they supposed to work? *PLEASE DISCUSS*
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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]