sca-bpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: BPEL Process: References with Multiplicity 0..1 - how are they supposed towork? *PLEASE DISCUSS*
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS BPEL" <sca-bpel@lists.oasis-open.org>
- Date: Sun, 19 Jul 2009 21:01:56 +0100
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]