-1 to this issue.
In <catch> and <reply> BPEL refers to a fault name by a QName. It might be
possible to change <reply> so it references the faultName by NCName,
because the portType and operation information is available here. But on
<catch> this context information is not available and a QName is really
required. Therefore BPEL currently introduces the restriction that a
faultName must be unique within a targetNamespace to fulfill the QName
uniqueness constrain and this should not be changed with respect to XML
Namespaces.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Prasad Yendluri
<pyendluri@webmet
hods.com> To
Alex Yiu <>
21.07.2006 02:05 cc
, Thomas
Schulze/Germany/IBM@IBMDE, Diane
Please respond to Jordan <>, Peter
pyendluri@webmeth Furniss
ods.com <>
Subject
Re: [wsbpel] new issue -
clarification on whether the QName
of a fault needs to be unique
across all portTypes and operations
I just replied to the other related thread on this and just noticed Alex
submitted a new issue.
+1 to this issue.
We should not force fault-names to be unique across portTypes or across
different operations in a portType.
Please see:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200607/msg00054.html
Regards,
Prasad
-------- Original Message --------
Subje [wsbpel] new issue - clarification on whether the QName of a fault
ct: needs to be unique across all portTypes and operations
Date: Thu, 20 Jul 2006 15:51:09 -0700
From: Alex Yiu <>
To:
CC: Alex Yiu <>, Thomas Schulze
<>, Diane Jordan <>, Peter
Furniss <>
Refer <.c
ences om> "><>
:
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
,
Alex Yiu
<>
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
