Hi Prasad,
so the only *new* limitation with this proposal would be that portTypes and
operatins must not contain the "." character when used with BPEL. Right?
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Prasad Yendluri
<pyendluri@webmet
hods.com> To
Thomas Schulze/Germany/IBM@IBMDE
24.07.2006 13:44 cc
,
,
Subject
Re: [wsbpel] new issue -
clarification on whether the QName
of a fault needs to be unique
across all portTypes and operations
Hi Thomas,
Yes, in the proposal I made, the BPEL faultName is always a QName.
Instead of the current scheme to derive BPEL faultName QName for WSDL
faults that does not result in unique QNames,
the proposal uses all components of portType as below:
BPEL faultName QName = <PortType-Namespace>:<portType
name>.<operationname>.<fault name>
The namespace prefix in the QName is WSDL fault's portType Namespace (same
as now).
The localPart (string after ':') uses all components of the portType of the
WSDL fault.
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 faultName 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 faultName QName is:
targetNamespace:shippingPT.requestShipping.cannotCompleteOrder
This eliminates the need for the current restriction we have. Per WSDL 1.1
component model, fault names need be unique within the scope of an
"operation" of a portType only. This proposal does not constrain that
further.
Regards,
Prasad
Thomas Schulze wrote:
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
