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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|