← Prev in month
← Prev in thread
Re: [wsbpel] Re: Issue 304 - discussion - clarification on whether theQName of a fault needs to be unique across all portTypes and operat ions
If we are able to agree on using QNames in BPEL without requiring them to
point to unique fault names in WSDL, would the following be acceptable
specification language (note that [SA00049] is no longer needed)?
Section 10.3 - change from:
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 port type and
the fault name. [SA00049] To ensure uniqueness, this uniform naming
mechanism MUST be followed even though it does not match the WSDL’s
fault-naming model. WSDL 1.1 does not require fault names to be unique
within the namespace where the service operation is defined. Therefore,
in WSDL 1.1 it is necessary to specify a port type name, an operation
name, and the fault name to uniquely identify a fault. Using WSDL 1.1's
scheme would limit the ability to use fault-identification and handling
mechanisms to deal with invocation faults.
to:
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 port type 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. WSDL 1.1 does not require fault names to be
unique within the namespace where the service operation is defined.
Therefore, in WSDL 1.1 it is necessary to specify a port type name, an
operation name, and the fault name to uniquely identify a fault. Using
WSDL 1.1's scheme would limit the ability to use fault-identification
and handling mechanisms to deal with invocation faults.
Section 12.5 - change from:
Data thrown with a fault can be a WSDL message type or a XML Schema
element. Each <catch>, which specifies a QName as its faultName
attribute value, can only catch a fault matching that particular QName.
This one-to-one relationship is necessary in order to guarantee proper
targeting for fault catching. If the data to be caught is a WSDL message
then the faultMessageType attribute is used to specify the message
type’s QName. If the data to be caught is a XML element then the
faultElement attribute is used to specify the element definition’s
QName.
to:
Data thrown with a fault can be a WSDL message type or a XML Schema
element. Each <catch>, which specifies a QName as its faultName
attribute value, can only catch a fault with a matching QName (see
section 10.3. Invoking Web Service Operations - Invoke for the
description of how to construct this QName from a fault defined in WSDL)
. Faults with the same name defined in multiple WSDL operations within
the same WSDL namespace can be caught by the same <catch> fault handler.
If the data to be caught is a WSDL message then the faultMessageType
attribute is used to specify the message type’s QName. If the data to be
caught is a XML element then the faultElement attribute is used to
specify the element definition’s QName.
Kind Regards
DK
Dieter König Mail: IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com> To
25.07.2006 02:15 cc
Thomas Schulze/Germany/IBM@IBMDE,
,
, Alex
Yiu <>
Subject
Re: [wsbpel] Re: Issue 304 -
discussion - clarification on
whether the QName of a fault needs
to be unique across all portTypes
and operat ions
Our email just crossed each other. :-)
I think we are converging.
Some clarification changes needs to be applied to the "one-to-one" wording
as well.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Hi Alex,
I am ok with clarifying in the area you mention. However we cannot
say in the same spec faultName QNames uniquely identify the faults in
one part and not in other parts. I think we need to clarify the text
in section 12.5:
"Data thrown with a fault can be a WSDL message type or a XML Schema
element. Each <catch>, which specifies a QName as its faultName
attribute value, can only catch a fault matching that particular
QName. This one-to-one relationship is necessary in order to
guarantee proper targeting for fault catching. "
Regards,
Prasad
From: Alex Yiu [mailto:]
Sent: Monday, July 24, 2006 4:28 PM
To:
Cc: Thomas Schulze; ;
; Alex Yiu
Subject: Re: [wsbpel] Re: Issue 304 - discussion - clarification on
whether the QName of a fault needs to be unique across all portTypes
and operations
Hi Prasad,
I understand where you are coming from.
WS-BPEL fault name identification is different from WSDL 1.1. And,
that has been the fault name design of WS-BPEL 1.1 and 2.0 design for
a long while. And, that has been intentional for simplicity and
unification of fault handling from different sources: WSDL operation
and internal BPEL logic.
And, the green text highlighted in a previous email shows that is not
by accident or mistake.
------------------------------
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 port type and the fault name. [SA00049]To ensure
uniqueness, this uniform naming mechanism MUST be followed even
though it does not match the WSDL’s fault-naming model. WSDL 1.1 does
not require fault names to be unique within the namespace where the
service operation is defined. Therefore, in WSDL 1.1 it is necessary
to specify a port type name, an operation name, and the fault name to
uniquely identify a fault. Using WSDL 1.1's scheme would limit the
ability to use fault-identification and handling mechanisms to deal
with invocation faults.
Faults in WS-BPEL are defined only in terms of a fault name and
optional fault data. This means, for example, that if a fault is
generated from a messaging activity (as opposed to the <throw>
activity (see section 10.6. Signaling Internal Faults) or a system
fault), there is no need to keep track of the port type or operation
the message activity was using when the fault was received. In
consequence, all faults sharing a common name, defined in the same
namespace and sharing the same data type (or lack thereof) are
indistinguishable in WS-BPEL. Faults of a particular name may be
associated with multiple variable types. The <catch> construct in
WS-BPEL facilitates differentiation of faults with the same name, but
with different message or variable types. For details regarding fault
handling and <catch>, see section 12.5. Fault Handlers.
------------------------------
In order to deliver the spec on time, let's stick with this current
semantics and clarify that underlined sentence.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Hi Alex,
We are not introducing a new feature. We need to fix the feature that
is totally broken in WS-BPEL currently.
The spec text that reads
"This results in a fault identified in WS-BPEL by a QName formed by
the target namespace of the corresponding port type and the fault
name."
is plain incorrect. We cannot define this to be a QName when the
localpart has no chance of being unique in a given WSDL namespace and
symbol space. We cannot pretend something is a QName when it is not
(and violate the XML Namespaces W3C recommendation as well as the
WSDL component model and symbol space division). WSDL 1.1 section
2.1.1 clearly states only the following types of definitions
contained in a WSDL document may be referenced as QNames:
WSDL definitions: service, port, message, bindings, and
portType
So, a <wsdl:fault> "name" @ by itself cannot form the localPart in
a QName.
Thomas is 100% correct in pointing out that to achieve this, BPEL
also needs to constrain this aspect in WSDL 1.1 so that no two
faultNames in a WSDL namespace can use the same value. That of course
has two major draw-backs of (1) not permitting reuse of same
faultNames for the same fault in multiple WSDL operations and
portTypes and (2) not permitting WS-BPEL processes to be defined
based on existing Web services that do not follow this restriction.
So, I see the simple fix to this is to change the currently flawed
WS-BPEL faultName derivation scheme or relax faultName not to be a
QName.
We cannot leave in this fundamental and major flaw in the WS-BPEL
specification. We need to fix it.
Regards,
Prasad
Alex Yiu wrote:
Hi Guys,
Let us use this email subject to correlate the email messages. So all
the discussion messages will be collected on the issue list.
I would like to make a few points here:
[a]
The intention of this issue openning is to clarify the statement
quoted in this issue description. I do not intend to add any new
features here.
[b]
Hence, I am not sure changing the faultName definition to "
<PortType-Namespace>:<portType name>.<operation name>.<fault name>"
or adding new attribute such as faultPortType to <catch> is a good
idea. I concur others that it would just make a relatively
complicated <catch> more complicated.
Also note that fault comes from two sources within BPEL: from a WSDL
operation or from executing a <throw> activity within a BPEL Process.
We have been treating them homogeneously for last 3 yrs of BPEL 2.0
cycle. And,we need to continue doing so, for simplicity and
usability. That is another reason why we may not want to add portType
info to <catch>. I tend to think allow users to add portType and
operation name in <catch> is a nice to have feature. Not, a
must-have. In terms of 80-vs-20 usecase, it would fall into the 20%
side (or even 10% side).
[c]
Let me quote the related spec text again here:
------------------------------
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 port type and the fault name. [SA00049]To ensure
uniqueness, this uniform naming mechanism MUST be followed even
though it does not match the WSDL’s fault-naming model. WSDL 1.1 does
not require fault names to be unique within the namespace where the
service operation is defined. Therefore, in WSDL 1.1 it is necessary
to specify a port type name, an operation name, and the fault name to
uniquely identify a fault. Using WSDL 1.1's scheme would limit the
ability to use fault-identification and handling mechanisms to deal
with invocation faults.
Faults in WS-BPEL are defined only in terms of a fault name and
optional fault data. This means, for example, that if a fault is
generated from a messaging activity (as opposed to the <throw>
activity (see section 10.6. Signaling Internal Faults) or a system
fault), there is no need to keep track of the port type or operation
the message activity was using when the fault was received. In
consequence, all faults sharing a common name, defined in the same
namespace and sharing the same data type (or lack thereof) are
indistinguishable in WS-BPEL. Faults of a particular name may be
associated with multiple variable types. The <catch> construct in
WS-BPEL facilitates differentiation of faults with the same name, but
with different message or variable types. For details regarding fault
handling and <catch>, see section 12.5. Fault Handlers.
------------------------------
The GREEN text shows that it is a clear and conscious decision that
BPEL does NOT exactly following the WSDL 1.1 fault naming. That is,
one faultName does not always match to exactly one fault defined in
WSDL.
The core question around this issue is: whether the underlined text
above disallow the one-to-many mapping case (as Thomas read it).
My reading is: the phrase of "ensure uniqueness" used by some spec
edtior gives unintended implication or interpretation. Because:
(I)
Bear in mind again that, we also allow the same faultName defined in
WSDL to be thrown within a BPEL process by a <throw> activity. If the
spec really intends to achieve the global uniqueness (based on
Thomas' interpretation) here, there should be an explicit statement
in <throw>, which say any WSDL defined fault cannot be used by a
<throw>. But, it is saying the opposite (see blue text):
--------------------------------
WS-BPEL does not require fault names to be defined prior to their use
in a <throw> activity. This provides a lightweight mechanism to
introduce business-process faults. A fault name defined in a business
process, a WSDL definition or a WS-BPEL standard fault can be
directly used, by using an appropriate QName, as the value of the
faultName attribute and providing a variable with the fault data if
required.
--------------------------------
(II)
The second part of the green text:
"In consequence, all faults sharing a common name, defined in the
same namespace and sharing the same data type (or lack thereof) are
indistinguishable in WS-BPEL."
(III)
And, WS-I does not have such a global uniqueness restriction pattern.
Given the role of BPEL spec, it is just infeasible that we can ever
enforce this restriction based on Thomas's interpretation. If that
was the interpretation of the spec, that would be the first thing
that customer will complain about ... "why in the world my WS-I
complaint WSDL are rejected by your BPEL processor?"
[d]
Thomas Schulze wrote:
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.
Thomas ... I am not sure I follow your elaboration here.
However, I do think the "global uniqueness" interpretation was based
on an overlooked usage of "to ensure uniqueness" in the spec text by
some previous spec editing. I hope I have convinced you that the true
intention of the spec is to allow one fault name (QName) mapped to
many fault definitions (from different operation/portTypes and
<throw> usages), after reading the green and blue text that I quoted
above.
[e]
Submitter proposal:
To avoid misinterpretation of the spec, suggest to change
from: "To ensure uniqueness"
to: "To ensure consistent fault identification"
After this clarification, we need to double check whether there is a
real static analysis enforceable here.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Thomas,
The whole QName is the faultName in the WS-BPEL domain including the
<catch> block.
If you need the WSDL faultName, then based on the potyType and
operation names you can extract the correct name.
Regards,
Prasad
Thomas Schulze wrote:
Hi Prasad,
in case this portType contains a fault and you like to reference it
in
<catch> according to your proposal, the faultName QName would look
like
this:
targetNamespace:My.Port.Type.My.Operation.faultName
Right? The portType "My" containing the operation "Port" defining the
faultName "Type.My.Operation.faultName" is not meant here.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
IBM Deutschland Entwicklung GmbH, IBM Lab Boeblingen
WSS - Business Process Solutions - BPC Development 2
Schoenaicher Strasse 220, 71032 Boeblingen, Kst. 3056, Geb. 7103-02,
Raum
0006
Phone: +49-7031-16-3094 (T/L: *120-3094); E-Mail:
Prasad Yendluri
<pyendluri@webmet
hods.com> To
Thomas Schulze/Germany/IBM@IBMDE 24.07.2006 16:14
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,
I do not see a problem. Can you please explain why you think there
would be
a problem?
Regards,
Prasad
Thomas Schulze wrote:
Hi Prasad,
a portType definition like the following would lead to problems,
IMHO:
<portType name="My.Port.Type">
<operation name="My.Operation">
...
</operation>
</portType>
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Prasad Yendluri
<pyendluri@webmet
hods.com>
To
Thomas
Schulze/Germany/IBM@IBMDE
24.07.2006 15:53
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,
Why do we need such a limitation? The local part is just an
NCName
(i.e. the LocalPart of the QName).
Regards,
Prasad
Thomas Schulze wrote:
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
← Prev in month
← Prev in thread