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 <alex.yiu@oracle.com>
21.07.2006 02:05 cc
wsbpel@lists.oasis-open.org, Thomas
Schulze/Germany/IBM@IBMDE, Diane
Please respond to Jordan <drj@us.ibm.com>, Peter
pyendluri@webmeth Furniss
ods.com <peter.furniss@erebor.co.uk>
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 <alex.yiu@oracle.com>
To: wsbpel@lists.oasis-open.org
CC: Alex Yiu <alex.yiu@oracle.com>, Thomas Schulze
<ThomasSchulze@de.ibm.com>, Diane Jordan <drj@us.ibm.com>, Peter
Furniss <peter.furniss@erebor.co.uk>
Refer <OFB99DE239.58A80A52-ONC12571B1.00763042-C12571B1.007723B0@de.ibm.c
ences om> 44C0020D.5010105@oracle.com"><44C0020D.5010105@oracle.com>
:
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
|