New issue:
---------------------------------------------
Subject: clarification on whether the QName of a fault needs to
be unique across all portTypes and operations
Description:
The spec text related to SA00049:
"This results in a fault identified in WS-BPEL by a QName formed by the
target namespace of the corresponding portType and the fault name. To
ensure uniqueness, this uniform naming mechanism MUST be followed even
though it does not match the WSDL’s fault-naming model ..."
Does that text require the QName of a fault needs to be unique across
all portTypes and operations? That is: two different operations within
the same portType or two different portTypes of the same TNS define the
same fault name (potentially with two different message types).
Are these cases of WSDL design legal and usable by WS-BPEL?
It seems to me that the intention of phase "to ensure uniqueness" is
unclear. Does it just mean a uniform behavior? Or, it tries to enforce
universally unique across all WSDL definitions?
Questions to consider:
- Does WS-I have a similar universally-unique restriction? If not, we
may have problems in taking WS-I complaint WSDL pattern?
- With <throw>, one can associate one faultName with more than
one faultMessageTypes already. Then, what does this
universal-uniqueness restriction buy us in terms of <catch>
construct usage?
---------------------------------------------
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Thomas,
Thanks for the reply.
I would double check with WS-I people as well. Most likely, I would
open a clarificaiton issue.
Two more data points to consider:
- Does WS-I have a similar restriction? If not, we may have problems in
taking WS-I complaint WSDL pattern?
- With <throw>, one can associate one faultName with more than
one faultMessageType already. Then, what does this restriction buy us?
Most likely, I would open issue to request a clarification on that
front.
Thanks!
Regards,
Alex Yiu
Thomas Schulze wrote:
Hi Alex,
I think SA00049 (that's the current SA code; I changed the subject,
too)
and the current wording in the spec in paragraph 10.3 is very clear. It
requires uniqueness of the QName "{ns of the portType}faultName" and
NOT
only uniqueness of the faultName inside a portType. We don't like to
change
this.
In the initial example the two mentioned portTypes are declared in the
same
targetNamespace "http://manufacturing.org/wsdl/purchase" and both
declare
the faultName "cannotCompleteOrder". This means the faultName QName
{http://manufacturing.org/wsdl/purchase}cannotCompleteOrder
is NOT unique and thus, the initial example is not valid according to
the
current spec. That's why I propose to just fix the initial example.
In case you'd like to change this rule in the spec, you should open a
new
issue.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Alex
Yiu
<alex.yiu@oracle.
com> To
Thomas
Schulze/Germany/IBM@IBMDE 19.07.2006
19:25 cc
wsbpel@lists.oasis-open.org,
Alex Yiu
<alex.yiu@oracle.com>
Subject Re: [wsbpel] Initial
example violates
SA00050?
Hi Thomas and others,
Quick gut feeling response.
I don't think the example violates the fault naming requirement imposed
by
the spec.
"This results in a fault identified in WS-BPEL by a QName formed by the
target namespace of the corresponding portType and the fault name. To
ensure uniqueness, this uniform naming mechanism MUST be followed even
though it does not match the WSDL’s fault-naming model ..."
IMHO, it does NOT imply or enforce that the faultName QName must be
unique
by across all portTypes.
However, I agree that the underlined sentence sounds a bit ambiguous to
me.
That is what is the uniqueness it is referring to???
"This results in a fault identified in WS-BPEL by a QName formed by the
target namespace of the corresponding portType and the fault name. To
ensure consistent fault identification, this uniform naming mechanism
MUST
be followed even though it does not match the WSDL’s fault-naming
model
..."
**IF** the sentence did enforce that the faultName QName must be unique
by
across all portTypes, the semantic would be very strange. When mapped
to
OOP world, interfaces of the same package cannot throw the same
Exception?
Thomas ... if you disagree with my interpretation, we may need to open
our
last BPEL issue on that. (sorry to john and diane in advance)
Thanks!
Regards,
Alex Yiu
Thomas Schulze wrote:
The initial example in 5.1 introduces the WSDL fault
'cannotCompleteOrder'
two times, one for portType 'purchaseOrderPT' operation
'sendPurchaseOrder'
and one for portType 'shippingPT' operation 'requestShipping'.
This
violates SA00050 (v26 of the SA List):
"In the case of a request-response invocation, the operation might
return a
WSDL fault message. This results in a fault identified in WS-BPEL
by
a
QName formed by the target namespace of the corresponding portType
and the
fault name. To ensure uniqueness, this uniform naming mechanism
MUST
be
followed even though it does not match the WSDL’s fault-naming
model."
Should this be fixed before the freeze? If yes, some adaptions to
5.6
are
necessary, too...
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
|