So reading back over this, and swapping as much of it as I can grasp
back in, I'm thinking that we can't support 0..1 with a variable, as I
was leaning towards on the call.
IF we define 0..1 as in this email thread, which I think is reasonable,
then we only have to deal with Mike's 2 issues as below.
Issue 1
I'm not sure I understand the issue, to be frank. Or if it's still
relevant? Let's reopen discussion of this.
Issue 2
Again, I don't have a problem with dealing with exceptions. But I'm
not unsympathetic to the problem that Mike has. So I'll again propose
new syntax. I was thinking on the call that it would be an extension
activity that would look something like:
<bpel:extensionActivity>
<sca-bpel:ifPartnerRoleSet partnerLink="pLinkName">
<bpel:activity/>
<sca-bpel:else>
<bpel:activity/>
</sca-bpel:else>
</sca-bpel:ifPartnerRoleSet partnerLink="pLinkName">
</bpel:extensionActivity>
And we could decompose the functionality into a virtual test and
catch. However, as I'm typing that, I think that providing an sca-bpel
xpath extension function would be far simpler. This would follow the
same lexical rules as bpel:getVariableProperty, namely:
[SA00030] The arguments to bpel:getVariableProperty MUST be
given as quoted strings. The previous requirement MUST be statically
enforced. It is therefore illegal to pass into a WS-BPEL XPath function
any XPath variables, the output of XPath functions, a XPath location
path or any other value that is not a quoted string. This means, for
example, that bpel:getVariableProperty("varA","b:propB") meets the
previous requirement while bpel:getVariableProperty( $varA,
string(bpel:getVariableProperty("varB", "b:propB") ) does not. Note
that the previous requirement institutes a restriction which does not
exist in the XPath standard.
sca-bpel:isPartnerRoleSet('partnerLinkName') would return true if the
role is set, and false otherwise. Still explain in spec as virtual
test and catch. Or leave that as an exercise to the reader.
Danny
On 8/13/2009 8:24 AM, Mike Edwards wrote:
Folks,
This is all good stuff, but I'd
still
like us to turn our attention to the original question of this issue.
How are 0..1 multiplicity references
supposed to work?
The text below clarifies the
circumstances
under which the process will be introspected to find a 0..1 reference.
But that still does not mean that
there
is a good description of how they work.
Issue 1:
Given that the BPEL spec does not
require
initialization of a partnerLink configured in the way stated to be
interpreted
as
a 0..1 multiplicity reference, how
is
any value of a target specified in SCA configuration for that reference
supposed to
get into the partnerLink variable?
- are we going to make a statement
that
the variable MUST be initialized (removing the MAY wording of the BPEL
spec)?
- are we going to a supply the value
of the reference in some other way so that he process can initialize
the
partnerLink variable
(I am thinking of a procedure
similar
to that of the handling of 0..n and 1..n references)
Issue 2:
Given that a 0..1 multiplicity
reference
can be configured at the SCA level with 0 targets, how is the BPEL
process
supposed to
find out that there are no targets?
It is not possible to inspect the contents of a partnerLink directly
from the BPEL process.
I heard one approach mentioned in
previous
discussions - let the invocation of the partnerLink take place and fail
with a
fault and deal with the fault.
I must say that I don't like this procedure at all - faults should be
used
for genuine problem
situations. A 0..1 reference that
is unwired is not a problem - it is expected.
One possibility is to have the
partnerLink
initialized but without an EPR present - I believe that this CAN be
tested
for and
also makes no presumption about the
form of the epr - the partnerLink would contain the <sref/> with
no child elements,
which can be tested for by the BPEL
process fairly simply.
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
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 ŭ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: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
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
|