[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 301 - Uninitialized Partner Links
Dieter Koenig1 wrote:
Agreed.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 The expected behaviour is unspecified. Consider the following: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? <assign>when the source partnerLink "foo" is uninitialized. According to section 8.1 (Variables): There is no equivalent language discussing how uninitialized partnerLinks are to be handled. The <copy> could cause a fault (but what kind?), or the copy could uninitialize the partnerRole of the partnerLink named "bar", and wait until the process attempts to reference the partnerRole of "bar" (and throws a uninitializedPartnerRole fault). The specification does not answer these questions; implementors must choose, presumably by suiting their own tastes. Do we want to have such variability in implementations? As it stands, given the scenario outlined above, we could have three different behaviours, all for good reasons:
-Ron |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]