[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] [Issue 53] BPEL Process: References with Multiplicity 0..1 -how are they supposed to work?
Danny's XPath extension function could be used in a scenario like this:
<if>
<condition>sca-bpel:isPartnerRoleSet("pLink1")</condition>
<invoke partnerLink="pLink1" .../> <!-- use initialized partner link -->
<else>
<sequence>
<assign><copy><from ... /><to partnerLink="pLink1"/></copy></assign>
<invoke partnerLink="pLink1" .../> <!-- use assigned partner link -->
</sequence>
</else>
</if>
Without an SCA-BPEL XPath extension function, one may use fault handler +
retry logic:
<scope>
<catch faultName="bpel:uninitializedPartnerRole">
<sequence>
<assign><copy><from ... /><to partnerLink="pLink1"/></copy></assign>
<invoke partnerLink="pLink1" .../> <!-- retry with assigned partner
link -->
</sequence>
</catch>
...
<invoke partnerLink="pLink1" .../> <!-- first attempt -->
</scope>
HTH
Kind Regards
Dieter König
Senior Technical Staff Member, WebSphere Process Server Architect
IBM Software Group, Application and Integration Middleware Software
WSS Business Process Solutions
Phone: +49-7031-16-3426 IBM Deutschland (Embedded
image moved
to file:
pic17861.gif)
E-Mail: dieterkoenig@de.ibm.com Schönaicher Str. 220
71032 Böblingen
Germany
IBM Deutschland
Research &
Development
GmbH /
Vorsitzender des
Aufsichtsrats:
Martin Jetter
Geschäftsführung:
Erich Baier
Sitz der
Gesellschaft:
Böblingen /
Registergericht:
Amtsgericht
Stuttgart, HRB
243294
From: Mike Edwards <mike_edwards@uk.ibm.com>
To: OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 06.11.2009 11:19
Subject: Re: [sca-bpel] [Issue 53] BPEL Process: References with Multiplicity 0..1 - how are they supposed to work?
Danny,
Comments inline.
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
From: Danny van der Rijn <dannyv@tibco.com>
To: Mike Edwards/UK/IBM@IBMGB
Cc: OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 05/11/2009 19:14
Subjec Re: [sca-bpel] [Issue 53] BPEL Process: References with
t: Multiplicity 0..1 - how are they supposed to work?
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.
<mje>
The issue is a simple one, I believe.
If you read the WS-BPEL spec and the SCA BPEL spec, then at the moment, if
you have a partnerLink that qualifies as a 0..1 reference,
there is nothing that requires this partnerLink to be initialized.
1) I believe that the SCA BPEL specification should be modified to add a
statement that a partnerLink introspected as a 0..1 reference
MUST be initialized if the partnerLink has a reference target. This places
a requirement on any SCA BPEL runtime to do something,
which is otherwise not stated.
2) For the case where there is a partnerLink introspected as a 0..1
reference that has no reference target (the 0 case...) then what needs
to be done depends on how we solve Issue 2. If there is some kind of test
(as you propose) that permits the BPEL process to work out
that there is no reference target and thus not to call that partnerLink,
then I think that is OK.
</mje>
Issue 2
Again, I don't have a problem with dealing with exceptions. But I'm not
unsympathetic to the problem that Mike has.
<mje>
The problem I have with exceptions is that exceptions are fine when dealing
with things that are truly exceptional - ie not really supposed to
happen. But in BPEL, just as much as in Java, I think it is simply painful
using exceptions to handle things that are expected - something that
you'd really expect to deal with via an "if....then...else" kind of
construct. And worse, I think that BPEL is harder to write for the
exception
handling than Java (I'll wait to be howled down by the BPEL experts for
that comment!) - there is nothing quite as simple as the Java try...catch
construct.
So I am in favour of some new syntax such as you propose below.
</mje>
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.
<mje>
Could you show an example of this second case please?
I think I prefer this second case, but I'd like to see it "in action"
before I pass judgement...
The first case works, as you show above, but it is a tad cumbersome - and
if we can use the standard BPEL
if...else construct instead, I think that would be simpler and less
cumbersome. Placing requirements on the
SCA BPEL runtime for a special XPath function should not be too much of a
burden I would have thought.
</mje>
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
From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: OASIS BPEL <sca-bpel@lists.oasis-open.org>
Date: 12/08/2009 23:39
Subjec Re: [sca-bpel] [Issue 53] BPEL Process: References with
t: Multiplicity 0..1 - how are they supposed to work?
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
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]
