Hi Thomas,
[a]
Regardless whether we want to support faultType in BPEL 2.0, you
mentioned another good corner case that we need to clarify - i.e. when
element variable contains an element data which is NOT identical to the
element QName used in variable declaration. (similar to Mark's case)
E.g.:
---------------------
<scope>
...
<catch faultVariable="myFaultVar"
faultElement="foo:bar"> ... </catch>
...
<variable name="var1" element="foo:bar" />
...
<assign>
<copy keepSrcElementName="yes">
<from>
<literal>
<foo:bar2> ... </foo:bar2>
</literal>
</from>
<to variable="var1" />
</copy>
</assign>
<throw faultVariable="var1" />
...
</scope>
---------------------
Will the <catch> be activated?
I tend to say the answer is no.
If that is consensus among us, I would provide some more text to
tighten it up.
[b]
Well ... I am not going to repeat myself that much ... But, again ... I
see SubstitutionGroup based matching is 20% usecase, while general
schema type inheritance matching is 80% case of faultType feature.
"adding attributes to enable inheritance matching" in BPEL 3.0 and
forcing users to learn that new attribute for the 80% usecase is
something that I do not prefer. :-) ... I guess the technical reality
is a bit clearer now. But, it is a relatively subjective judgement call
on whether we want to sacrifice future standard usability in order to
standardize a 20% usecase in 2.0.
Thanks!
Regards,
Alex Yiu
Thomas Schulze wrote:
Hi Alex,
I agree with you regarding the odd cases (your examples 1 and 2), but I
think we already have them with elements, see my example in the previous
note (matching to your example 1) and the following (your example 2
slightly modified, matching to your example 2):
<scope></catch> </catch> element="foo:addressTypeElement" />element="foo:usAddressTypeElement" /> <from variable="usAddrVar"/> /> faultVariable="addrVar" />
</scope>
Because of QName matching and the default for keepSrcElementName="no" the
first catch is selected and not the second, right? Only when changing to
keepSrcElementName="yes" the second catch is selected, or the first, too?
So this is odd, too. In any cases, the user needs to know what he is doing.
In case when using elements and in case when using types.
Regarding backwards compatibility. I hope a future version of the spec will
put that much priority on backwards compatibility as you propose it ;-) The
most specifications I know haven't done that. That's why I really like your
proposal adding attributes to enable inheritance matching for a specific
<catch> ;-)
Best regards/Mit freundlichen Grüßen,
Thomas
Alex Yiu
<alex.yiu@oracle.
com> To
Thomas Schulze/Germany/IBM@IBMDE
30.05.2006 11:41 cc
Mark Ford
<mark.ford@active-endpoints.com>,
Dieter Koenig1/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 280 -
discussion
Hi Thomas,
See comments inline:
Thomas Schulze wrote:
Hi Mark and Alex,
I read all existing fault handling rules as Alex, QName matching
based on
the declaration in the WSDL. If the actual thrown element data's
QName does
not match the QName in a <catch faultElement="..."> it isn't catched
by
that <catch>. IMO, in the following example the <catch> currently
can't
catch the thrown variable and that's too true for rules 2 and 5:
<element name="E1" type="T"/>
<element name="E2" type="T"/>
<variable name="E1" element="E1"/>
<variable name="E2" element="E2"/>
scope
catch faultElement="E1"
...
throw variable="E2"
Means there is currently no support for cross-over catching (elements
of
the same type) or substitution groups. Maybe this needs a
clarification.
[AYIU]: [a] I hope my suggested additional text that I just sent out is
good enough to plug the holes and cure any ambiguity.
But exactly that's the reason why we propose to resolve issue 280 by
only
adding a faultType attribute to <catch> and do the matching by QName
according to the current rules 1 and 4. Like for elements, no support
for
inheritance and cross-over catching. Currently no type-matching is
supported and with this proposal we don't like to change that when
resolving this bug issue which only addresses the existing
inconsistency
between <throw> and <catch>.
For me, catching types is not only a 20% usecase. It's more a 50%
usecase,
I think. The current spec makes extensive use of examples with
multi-part
messages which parts are type-typed. And there are too a lot of
existing
WebServices which have an interface with such messages. To be able to
support those existing stuff fully, I think BPEL needs to be able to
throw
and catch types. As outlined in section 3 BPEL is open to support all
kinds
of WebServices and does not only concentrate on specific other
specifications.
[AYIU]: [b] I totally understand there are some values in adding support
for catching a type-based fault. But, it is still a judgment call between
the values of features and its complexities and risk of delaying the spec
and blocking future spec evolution. (See more below)
Alex, regarding "... make it difficult for future BPEL standard to
support
a richer semantics similar to the type-matching example above without
breaking backward compatibilities.":
When we decide to solve the bug by adding the possibility to catch
types,
this will be part of rule 1 and 4. In a future BPEL standard, rule 1
and 4
will still be the first rules which have to be considered first for
all
catch blocks. This means a <catch> which catches a type today will
catch it
too in the future, because new rules have to be added after rule 1
and 4. I
don't see there any future backwards compatibility problems. Far from
it, I
think this strict solution makes it easier to extend that in the
future.
[AYIU]:
[c]
Assume we have a <catch faultType="foo:addressType" > and it is matched by
a fault data declared with schema type of the exact QName. Consider the
following:
Example #1
---------------------------
<scope>...-->
<variable name="usAddrVar" type="foo:usAddressElem" />on foo:usAddressType -->
...</scope>
---------------------------
From user viewpoint, it is odd that if the <catch> does not catch the fault
triggered by "throw2". I am sure that will be complaint #1 for our users,
if we put this feature by QName matching only for schema type into the
spec. That would be too different from other programming langauges (e.g.
Java)
Example #2
---------------------------
<scope></catch> ...name="usAddrVar" type="foo:usAddressType" /><copy> variable="addrVar" /> name="throw1" faultVariable="addrVar" />
</scope>
---------------------------
That is another odd case. Even though the data is of "addrVar" is exactly
of the "usAddressType". But, the <catch> for usAddressType does not get
activated?
[d]
About future spec evolution and backward compatibility,
if BPEL 2.0 spec says:
<catch faultType="foo:addressType">
syntax matches the fault variable declared with type of exact QName only.
Then, in BPEL 3.0, we cannot extend its semantics to do inheritance
matching of the same syntax without breaking any backward compatibility.
Because, if the syntax does not catch certain faults in 2.0 then the same
syntax should not catch any new fault in 3.0.
At most, we can add a new switch to the syntax, then we can extend its
catching semantics. E.g.:
<catch faultType="foo:addressType" enableSchemaTypeInstanceMatching="yes">
For faultElement, when we want to support Subsitution Group in 3.0, then
we will need to add a new attribute. e.g.:
<catch faultElement="foo:bar" enableSubsitutionGroup="yes">
I am relatively comfortable with that because SG is not a frequently used
feature in schema. (Note: in JAXB 1.0, they even did not have SG support.)
Unlike type inheritance, SG has not parallel concepts in other programming
langauges. Developers of other programming languages would not feel
surprised.
On the other hand, derived-type are used more frequently in schema world
IMHO. Even if derived type is not used, catching an element-based fault
variable of the same type are still frequently expected. (See example #1
above)
If we add faultType feature, 80% usecase or users would need inheritance or
"instance-of" typing checking (instead of just exact QName matching). And,
it may not be a good idea to force users to learn and use a new switch in
BPEL 3.0 in order to enable a 80% usecase, while we try to standardize just
20% usecase of faultType in BPEL 2.0.
I hope my thinking process makes sense to you guys.
Thanks!
Regards,
Alex Yiu
Best regards/Mit freundlichen Grüßen,
Thomas
"Mark Ford"
<mark.ford@active
-endpoints.com>
To
"'Alex Yiu'"
<alex.yiu@oracle.com>
30.05.2006 06:36
cc
Dieter
Koenig1/Germany/IBM@IBMDE,
Thomas
Schulze/Germany/IBM@IBMDE,
<wsbpel@lists.oasis-open.org>
Subject
RE: [wsbpel] Issue - 280 -
discussion
The part of the rules that I'm questioning has to do with rule #2 and
#5
which cover the single element part WSDL message. Do you read this to
say
that the QName for the element comes from the actual element data or
the
declaration of the <part element="qname"/> in the WSDL? There are
cases
where the QNames could be different. It would be possible to
construct a
WSDL message variable and populate it with an element for use with a
<throw> that differed from the element QName in the part description.
Perhaps the element used was part of a substitutionGroup or perhaps
it was
simply user error. In either case, I'd like to clarify which QName to
use
for the element when matching.
Here's rule #2 with my emphasis:
2. Otherwise if the fault data is a WSDL message type where the
message contains a single part defined by an element and there exists
a
<catch> construct with a matching faultName value that has a
faultVariable
whose associated faultElement’s QName matches the QName of the
element used
to define the part then the fault is passed to the identified <catch>
construct with the faultVariable initialized to the value in the
single
part’s element.
It seems to me that we're driving this match based on the <part
element="qname"/> from the WSDL and not from the element data. If
this is
the intent, then it feels a little inconsistent since in the other
cases
we're basing the match on the contents of the data as opposed to some
declaration of its type. If this is not the intent, then perhaps this
section could do with a slight rewording to make it more clear?
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, May 29, 2006 9:35 PM
To: Mark Ford
Cc: 'Dieter Koenig1'; 'Thomas Schulze'; wsbpel@lists.oasis-open.org;
Alex
Yiu
Subject: Re: [wsbpel] Issue - 280 - discussion
Hi Mark,
Hope you had a good long weekend ... :-)
I would like to address your question about "ambiguities" of the last
part
of email.
The current rule is clear to me that we are doing an exact QName
match.
That is, substitutionGroup is not considered in the <catch> matching
logic.
Further elaboration: <catch faultElement="foo:bar"> will catch only
faults
that is of either element whose exact QName is "foo:bar" or message
type of
single part of element whose exact QName is "foo:bar". And, it will
NOT
catch a fault of element "foo:bar2" which is a part of
substitutionGroup of
"foo:bar".
Our current <catch> rule does not touch any XML schema typing issue
at all.
If in future we are ready to handle XML schema typing in our <cach>
matching rules, we can for sure consider adding support for
substitutionGroup at <catch> with a switch (that is a 20% usecase).
Back to commenting a bit more on Dieter's proposal: if we had
introduced
"faultType", that I would consider it is a 50%~80% of people would
expect
type-matching, instead of QName matching. That was also what I
mentioned to
Yaron back in Fall 2005. Yaron decided not to deal with the type
matching
problem by not introducing the "faultType" attribute in NY F2F (Dec
2005).
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
Does your proposal extend to elements as well? Specifically,
should
the
declared type of the element variable be considered as opposed
to its
actual
content?
I'm not sure if others have interpreted the rules as I have but
my
reading
is that the Qname of the element content drives the match
except in
the case
of a single part WSDL message which relies on the declared
type.
Regardless of this issue is resolved, I think we should clarify
the
fault
matching rules to remove an possible ambiguities. For example,
what
would
happen if I had a schema that used substitutionGroups and threw
a
fault with
an element within the substitutionGroup? Would the fault
matching be
driven
by the declared type which was the head of the group or by the
actual
data
which was one of the allowed substitutions?
-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Monday, May 29, 2006 10:00 AM
To: alex.yiu@oracle.com; Mark Ford
Cc: Thomas Schulze; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 280 - discussion
Hi Alex and Mark, rules 1 and 4 should take care of both
element and
type by
means of strict QName matching.
In other words,
- when a variable is defined with a type ns:t then it can be
caught
using a
faultType that specifies the same QName ns:t
- when a variable is defined with an element ns:e then it can
be
caught
using a faultElement that specifies the same QName ns:e
This clarification would need to be added to the two rules, and
the
faultType attribute be added to catch.
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
Alex Yiu
<alex.yiu@oracle.
com>
To
Mark Ford
24.05.2006 19:47
<mark.ford@active-endpoints.com>
cc
Thomas
Schulze/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org,
Alex
Yiu
<alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 280
-
discussion
Hi,
[ Changing the subject line ... such the issue list can
"correlate"
this
email thread ;-) ]
Currently, there is a set of rules stated in section "12.5
Fault
Handlers"
to determine which <catch> will be used during fault handling.
(under "in the case of faults thrown with associated date ...")
As Mark stated, if we want to support XSD-type (both simple and
complex
type) in the <catch> clause, we need to modify that set of
rules
significantly. There are 6 rules involved in that set. They are
just
using
element's QName matching and message type's QName matching
there.
The passed resolution intentionally avoid any type
inheritance-based
checking there.
If we allow simple-type or complex-type based <catch> clause,
it
would be
odd to some users, if we don't do any type inheritance-based
checking
(similar to Java catch). If we do inheritance-based checking
(e.g. a
"foo:AddressType" based <catch> can handle a
"foo:USAddressType"
fault), we
would wander in the territory of "best-match" schema type
semantics,
which I
am not sure any other spec has done that before.
If we don't do inheritance-based checking, it may not be that
simple
either
to resolve all the most appropriate <catch> either. e.g. which
one
will be
matched?
<catch faultType="foo:AddressType">
vs <catch faultElement="foo:AddressElem"> (where
"foo:AddressElem" is
based
on "foo:AddressType") vs <catch
faultMessageType="foo:AddressMsgType">
(where "foo:AddressMsgType" has a single part based on
"foo:AddressType")
I am quite sure if we spend enough time, there will be a
matching
algorithm
developed. But, at the same time, the 80-20 rules applies here.
That
is, we
may need to double the size of rules (from 6 to 12) for a 20%
usecase?
Complexity kills usability.
Last, it may be too late for this cycle of spec to add such a
new
feature to
<catch>.
I hope my train of thoughts sound reasonable to you guys.
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
I think this issue boils down to how we determine the
type of
the fault
data. The current matching rules match element data by
their
QNames.
There is a subtle difference with WSDL Message fault data
that
define a
single part of type element. In this case, the QName for
the
fault data
comes
from
the part's element type declaration as opposed to the
actual
data for
that part.
If we add support for type-typed variables, then we need
to
change how
the type of the fault data is determined. The existing
rules
for
determining
the
type of the fault data are insufficient in this regard
because
they
look only at the element data itself which could be
ambiguous
with
complex
types
and elements.
How do you propose to determine the type of the fault
data?
-----Original Message-----
From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com]
Sent: Tuesday, May 23, 2006 1:32 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] BPEL Issue 280
BPEL Issue 280 addresses an inconsistency between BPEL's
<throw> and
<catch>. While <catch> can only handle message-typed and
element-typed
data,
<throw> can additionally throw type-typed data. The
proposal is
to put
the restriction on <throw> to be able to throw only
message-typed and
element-typed data.
Before doing this, I would like to discuss the other
opportunity,
allowing <catch> to catch type-typed data.
Rationale:
The BPEL 2.0 spec builds on WSDL 1.1 which allows to have
messages with
multiple parts. These parts can either be element-typed
or
type-typed.
For instance, assume the following WSDL message (from the
initial
example in section 5.1):
<wsdl:message name="POMessage">
<wsdl:part name="customerInfo"
type="sns:customerInfoType"/>
<wsdl:part name="purchaseOrder"
type="sns:purchaseOrderType"/>
</wsdl:message>
Besides i.e. receiving such a message in a message-typed
variable, you
can use <fromPart>. This means, you can receive this
message in
two
type-typed
variables:
<bpel:variable name="CustomerInfo"
type="sns:customerInfoType"/>
<bpel:variable name="PurchaseOrder"
type="sns:purchaseOrderType"/>
<bpel:receive name="ReceivePOMessage" partnerLink="..."
operation="...">
<bpel:fromPart part="customerInfo"
toVariable="CustomerInfo"/>
<bpel:fromPart part="purchaseOrder"
toVariable="PurchaseOrder"/>
</bpel:receive>
Now imagine a process which makes use of only such
type-typed
variables.
They never can be thrown when resolving the issue as
proposed.
If a
modeler
of a BPEL process needs to throw such a variable, he is
forced
to
introduce
a new message or element making use of that type and then
throw
this
message-typed or element-typed variable.
This problem have already been discussed in Issue 93
(
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue93
).
The reasoning for not allowing to catch type-typed data
was:
"Throwing
complex types as faults is vaguely odd and WS-I requires
that
all SOAP
faults be defined using elements so in general Web
Services
faults are
typically elements anyway."
I think WS-I does not apply here, because <throw> and
<catch>
are BPEL
internal constructs. If a BPEL process should produce a
Web
Service
fault <reply> have to be used. BPEL does not put any
restrictions on
replying a fault. So why on throwing a fault?
Additionally remember chapter 8.1: "The infoset for a
complex
type
variable
consists of a DII that contains exactly one child, which
is an
EII
referenced by the document element property. ... However
the
children
of
the
document element MUST exclusively consist of the complex
type
values
assigned to the variable."
Does that mean that type-typed variables have to be
internally
represented as element-typed? (maybe one of the DII / EII
/ AII
/ TII
experts can
answer
that question) If yes, the catch logic shouldn't differ
that
much from
the existing when allowing to catch type-typed data.
I appreciate any comments/further thoughts on this. Tanks
in
advance!
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
|