[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 301 - Uninitialized Partner Links
I have not yet fully understood the issue 301.
My picture is as follows:
A. Variables and partner links are allowed to be declared but not used
- Note this is also true for correlation sets and message exchanges
B. Variables and partner roles of partner links are *used* when their value
is *read*
- Variables are used when they are referenced in <from> / <invoke> /
<reply>
- Partner roles of partner links are used when they are referenced in
<from> / <invoke>
C. Variables and partner roles of partner links can be uninitialized
- If they are *used* anyway then
uninitializedVariable/uninitializedPartnerRole is thrown
Questions:
1. Do we have agreement on A. & B. & C.?
2. If yes (1.), which part is left unclear by the spec?
Kind Regards
DK
Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
"Monica J.
Martin"
<Monica.Martin@Su To
n.COM> wsbpeltc
Sent by: <wsbpel@lists.oasis-open.org>
Monica.Martin@Sun cc
.COM Ron Ten-Hove
<Ronald.Ten-Hove@Sun.COM>, Alex Yiu
<alex.yiu@oracle.com>
21.06.2006 00:49 Subject
Re: [wsbpel] Issue - 301 -
Uninitialized Partner Links
From Ron and Monica:
On issue 301, Ron and I had an offline discussion with a few other TC
members (in hopes of answering any questions Dieter may have). Here is a
restatement of the issue we have raised which poses two related questions:
1. Unused partnerLinks: Are they allowed?
2. Assuming the answer to (1) is "yes": What kind of fault should
assignment from an uninitialized partnerLink cause?
We believe that the specification implicitly allows (1). This has caused
some confusion with reviewers of the specification within Sun, since
there is no explicit statement to this effect.
Assuming that (1) is true (we saw one use case where that could be
true), a further issue was identified. There is no statement in the
specification what sort of fault should be thrown if an uninitialized
partnerLink is used as the source (<from>) in an assignment operation.
Partner links are distinct from variables (so bpel:uninitializedVariable
isn't applicable), and this involves the whole partnerLink, not one role
within it (thus bpel:uninitializedPartnerRole doesn't apply).
In point of fact, the lack of any language addressing the second
question caused some reviewers to question the assumption contained in
the first. Surely the lack of a defined fault in (2) implies that
partnerLinks MUST always be uninitialized?
Therefore, by resolving (2), we should make (1) appear to hold
consistently throughout the specification. We can consider some type of
fault to handle (2), permit (1) to be allowed implicitly, and ensure
consistency with (1) because of (2).
Thanks.
>> ....Issue - 301 - Uninitialized Partner Links
>> *Status:* received
>> *Date added:* 15 Jun 2006
>> *Date submitted:* 12 June 2006
>> *Submitter:* Monica J. Martin <mailto:Monica.Martin@Sun.COM>
>> *Description:* Background: Questions were raised if it is valid to
>> have partnerLinks declared in a BPEL process which are not referenced
>> by any messaging activity (receive, invoke, onMessage, onEvent, etc)
>> whereby they are declared but not referenced. If they are to be used,
>> they need to be initialized to be used (and of course referenced in a
>> message activity). The specification talks about in Section 6.2 that
>> partner links can be dynamically bound outside of the process as
>> well. If the partner role is uninitialized a fault will occur (see
>> Section 10.3):
>>
>> If an <invoke> activity is used on a partnerLink whose partnerRole
>> EPR is
>> not initialized then a bpel:uninitializedPartnerRole fault MUST be
>> thrown."
>> In reviewing this question, we uncovered a potential gap when copying
>> one partner link to another in an assign where a partnerLink role is
>> unitialized.
>>
>> Example:
>>
>> <?xml version="1.0" encoding="utf-8" ?>
>> <process name="fhMatchingCatches1"
>>
>> targetNamespace="http://www.seebeyond.com/eInsight/MatchingCatches1";
>>
>> xmlns:tns="http://www.seebeyond.com/eInsight/MatchingCatches1";
>>
>> xmlns:bpel="http://schemas.xmlsoap.org/ws/2004/03/business-process/";
>> xmlns:ns0="http://stc.com/FaultTest/MatchingCatches1";
>> xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/";>
>> <import namespace="http://stc.com/FaultTest/MatchingCatches1";
>> location="MatchingCatches1.wsdl"
>> importType="http://schemas.xmlsoap.org/wsdl/";></import>
>> <partnerLinks>
>> <partnerLink name="faulttestLink" partnerLinkType="ns0:SLT"
>> myRole="server"/>
>> <partnerLink name="unusedPartnerLink1"
>> partnerLinkType="ns0:PLT2" myRole="role1"/> <!-notice that
>> these are not used in the business process -->
>> <partnerLink name="unusedPartnerLink2" partnerLinkType="ns0:PLT3"
>> partnerRole="role2"/>
>> </partnerLinks>
>> <variables>
>> <variable name="MatchingCatches1_Output"
>> messageType="ns0:FaultTest"></variable>
>> <variable name="MatchingCatches1_Input"
>> messageType="ns0:FaultTest"></variable>
>> </variables> <sequence>
>> <receive name="MatchingCatches1" partnerLink="faulttestLink"
>> portType="ns0:FaultTest"
>> operation="MatchingCatches1"
>> variable="MatchingCatches1_Output" createInstance="yes"/>
>> <assign name="Assign">
>> <copy>
>> <from>'Scenario Passes Thru'</from>
>> <to>$MatchingCatches1_Input.part/retString</to>
>> </copy>
>> </assign>
>> <reply name="Reply"
>> partnerLink="faulttestLink" portType="ns0:FaultTest"
>> operation="MatchingCatches1"
>> variable="MatchingCatches1_Input"/>
>> </sequence> Use cases: One use case was
>> identified that may explain why this was allowed (if only
>> indirectly): A partner link (not used by any messaging activity) can
>> be used as the source for an endpoint reference. A set of unused
>> partner links, and some BPEL logic to choose one of them to be
>> assigned to a partner link that is actually used. The unused partner
>> links would be bound to concrete addresses during deployment.
>>
>> <process>
>> partnerLink alpha
>> partnerLink beta
>> partnerLink gamma
>> sequence ...
>> if some-condition
>> assign from beta to alpha
>> else
>> assign from gamma to alpha
>> invoke operation bar on alpha ...
>> </process>
>>
>> However, the example and use case uncover the potential gap.
>> UninitializedVariable and UnitializedPartnerRole faults exist but
>> neither really applies to copying one partner link to another in an
>> assign. What if we execute: assign from beta to alpha
>>
>> And, beta (for the selected EPR) is not initialized? The
>> UninitializedVariable fault still works, but Variables are
>> distinction from PartnerLinks in BPEL. This is a problem that exists
>> and should be addressed regardless of the declaration and referencing
>> question that prompted this discovery.
>>
>> Question: In Section 12, we discuss partner links in several
>> contexts, such as for example, that any partner links defined in the
>> <scope> must be set before variables defined in the same <scope>
>> whose initialization logic refers to those partner links. However,
>> unless identified, I don't see any restrictions for a partner link to
>> be declared but remain unused, nor any restrictions on assignment.
>> *Submitter's Proposal:* (conceptual) Suggest we consider two explicit
>> restrictions that specify that it is invalid: 1) to have partnerLinks
>> declared in an executable BPEL process which are not referenced by
>> any messaging activity (receive, invoke, onMessage, onEvent, etc). If
>> they are to be used, they need to be initialized to be used. 2) for
>> an assignment from an uninitialized partnerLink role. It causes an
>> UninitializedVariable fault.
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]