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:alex.yiu@oracle.com]
Sent: Monday, July 24, 2006 4:28 PM
To: pyendluri@webmethods.com
Cc: Thomas Schulze; Ronald.Ten-Hove@Sun.COM;
wsbpel@lists.oasis-open.org;
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: ThomasSchulze@de.ibm.com
Prasad
Yendluri
<pyendluri@webmet
hods.com>
To
Thomas Schulze/Germany/IBM@IBMDE
24.07.2006
16:14
cc
alex.yiu@oracle.com,
Ronald.Ten-Hove@Sun.COM,
wsbpel@lists.oasis-open.org
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
alex.yiu@oracle.com,
Ronald.Ten-Hove@Sun.COM,
wsbpel@lists.oasis-open.org
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