Hi Prasad and Ron,
Adding two more attributes would only resolve the issue, if the faultName
attribute references a NCName, and no longer a QName (IMHO exactly this
rises the current uniqueness constraint):
<catch faultName="cannotCompleteOrder" portType="pos:purchaseOrderPT"
operation="sendPurchaseOrder">
...
</catch>
IMHO a solution for this issue must consider that <catch> should still be
able to catch the BPEL internal faults. They are all declared as QNames,
i.e. bpel:joinFailure, for which no portType and operation context
information is available. Additionally, <throw> can introduce new process
internal faults without any additional context information, too.
Ron, I think your proposed solution would not be able to address this
requirement (assuming faultName references a NCName) and I'm not 100% sure
in case of your solution, Prasad. Is the faultName attribute still a QName
in your case?
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Prasad Yendluri
<pyendluri@webmet
hods.com> To
Ron Ten-Hove
22.07.2006 01:32 <>
cc
Thomas Schulze/Germany/IBM@IBMDE,
Please respond to ,
pyendluri@webmeth
ods.com Subject
Re: [wsbpel] new issue -
clarification on whether the QName
of a fault needs to be unique
across all portTypes and operations
Hi Ron,
I think your first option really boils down to not unique case. Thomas had
concerns with <catch> not having enough information on the fault if the
Fault Names (QNames) are not unique in a given namespace (of the portType).
Your second option is more attractive to me. However <catch> already has
too many options and confusing permutations and combinations of those
options (current syntax below):
<catch faultName="QName"?
faultVariable="BPELVariableName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity </catch>
Adding two more attributes seems would make it worse. Also showing a
portType and Operation on <catch> like below, could draw parallels with
<receive> syntax where the message is received from the portType and
operation by the activity directly?
<catch faultName="pos:cannotCompleteOrder" portType="pos:purchaseOrderPT"
operation="sendPurchaseOrder">
...
</catch>
In either case, either the approach above or the QName derivation scheme I
proposed below that make fault names unique in a namespace without
constraining the WSDL model, would make a viable solution to this issue
IMO.
Regards,
Prasad
Ron Ten-Hove wrote:
Prasad, Exploring your first option (getting rid of the uniqueness
restriction) will lead, in some cases, to ambiguous <catch>
activities, where the fault name can be mapped to more than one fault
declaration in the portType definitions used by the process. In
some cases, the existing <catch> messageType attribute would serve to
disambiguate the faults. In other cases, including the example in
front of use, it is not sufficient, for both faults have the same
type (pos:orderFaultType). We could declare that under such
circumstances, the <catch> with receive faults from both operations,
explicitly allowing this type of ambiguity. I can't see too many
issues arising out of two allowing two different fault sources, where
the fault has the same name and type. If there were two separate
faults with the same name but different types (massaging our example
slightly):
<catch faultName="pos:cannotCompleteOrder"
faultMessageType="pos:secondOrderFaultType">
...
</catch>
Alternatively, we could add some extra attributes to the <catch>
to disambiguate the source of the fault: portType and operation.
Going back to our example (without massaging):
<catch faultName="pos:cannotCompleteOrder"
portType="pos:purchaseOrderPT" operation="sendPurchaseOrder">
...
</catch>
This approach seem less intrusive than inventing a way of mapping
the <portType, operation name, fault name> tuple to a QName.
Regardless of solution, I think this is a real issue.
-Ron
Prasad Yendluri wrote:
I think we need to derive the QNames without violating the WSDL
fault definition model.
If we force major WSDL level restrictions like this, it becomes
impossible to integrate existing Web services into business
process, without fist revamping the interface definitions to
use unique fault names (for the same fault) at each operation
in a portType as well as at all portTypes in a WSDL. Then the
revamped Web services (with new interface definitions) need to
be redeployed, impacting all existing clients.
Only solutions I see are:
(1) to get rid of this uniqueness restriction totally at
WS-BPEL level and figure out a way to deal with it.
(2) to integrate, all of the portType namespace, portType
name, operation name and fault name into the QName so that we
will still have unique fault name at WS-BPEL level without
degrading WSDL model.
E.g. <PortType-Namespace>:<portType name>.<operation
name>.<fault name> (if we don't line . we can use any separator
a NCName syntax allows)
So, in the case of Initial Example in section 5.1, for these
two portTypes where targetNamespace=
"http://manufacturing.org/wsdl/purchase"
<wsdl:portType
name="purchaseOrderPT"> <wsdl:operation
name="sendPurchaseOrder"> <wsdl:input
message="pos:POMessage"/> <wsdl:output
message="pos:InvMessage"/> <wsdl:fault
name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</wsdl:operation> </wsdl:portType>
The BPEL level fault Qname is:
targetNamespace:purchaseOrderPT.sendPurchaseOrder.cannotCompleteOrder
and for <wsdl:portType
name="shippingPT"> <wsdl:operation
name="requestShipping"> <wsdl:input
message="pos:shippingRequestMessage"/>
<wsdl:output
message="pos:shippingInfoMessage"/>
<wsdl:fault
name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</wsdl:operation> </wsdl:portType>
The BPEL level fault Qname is:
targetNamespace:shippingPT.requestShipping.cannotCompleteOrder
This eliminates the need for the restriction as, per WSDL 1.1
component model, fault names must be unique within the scope of
an operation.
Regards,
Prasad
Thomas Schulze wrote:
-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
