Title: Message
Hi
Satish,
After
thought a little bit more on this, I realize I was wrong about
headerfault.
The
wsdl1.1 soap binding is very vague on how headerfault should be
defined/used, but reasonable guess would be put the whole soap:fault
structure under soap:header. If that's the case, even one can define a
message that contains elements such as "faultcode", "faultstring" etc, these
elements are not in the soap namespace. Basically, Satish was right that we have
exactly the same issue with headerfault.
As
that said, I think the text below still works fine, it covers both body
fault and headerfault.
Best Regards,
Kevin
-----Original Message-----
From: Satish Thatte
[mailto:]
Sent: Thursday, Jan 13, 2005 09:19
AM
To: Liu, Kevin; Kartha, Neelakantan; bpel spec
Subject:
RE: [wsbpel-spec-edit] Proposed text for issue 170
(RESEND)
Thanks Kevin. It is
strange that this problem was created in such an inconsistent way. If you are
going to mess things up you should at least do so thoroughly. Then are a few
grammatical nits in the text below but otherwise we are ready to go I
think.
From: Liu,
Kevin [mailto:]
Sent: Tuesday, January 11, 2005 11:16
AM
To: Kartha, Neelakantan;
bpel spec
Subject: RE:
[wsbpel-spec-edit] Proposed text for issue 170
(RESEND)
Hi
Kartha,
As promised I have
just checked the wsdl1.1 spec and here is my take on
170:
1. the text proposed
below looks fine to me
2. section 11.4 is
more appropriate than section 13.4 since the text is talking about fault
variables, not fault handling
3. As for the
headerfault problem Satish mentioned this morning, it's actually not an
issue. Unlike soapfault which only allows mapping a
wsdl:fault message to faut detail element, Headerfault can point to an
abstract message that explicitly define faultcode, faultactor, faultstring,
and faultDetail
Hope this
helps.
Best
Regards,
Kevin
-----Original
Message-----
From: Kartha,
Neelakantan [mailto:]
Sent: Tuesday, Jan 11, 2005 09:54
AM
To: bpel
spec
Subject:
[wsbpel-spec-edit] Proposed text for issue 170 (RESEND)
Here is the
proposed text for 170 (resent, as requested by
Satish).
Best,
Kartha
-----Original
Message-----
From:
Kartha, Neelakantan [mailto:]
Sent: Friday, December 03, 2004 1:20
PM
To: bpel
spec
Cc: Satish Thatte;
Subject:
[wsbpel-spec-edit] Proposed text for issue 170
Here
is the proposed text (which is a modification Yaron's text with
elements of my original text). Both of the latter
are
also included in this message for easy comparison.
Implementer's Note:
BPEL treats faults generically, without respect to
which particular
transport they have been bound to. Normally, when
sending or receiving a
fault, a BPEL would specify generic fault
information in the
abstract fault message and then a WSDL 1.1 binding
would transform that
generic information into/from specific error
information unique to
the transport being bound to. In the case of SOAP
this would mean
providing a mapping between generic fault data and the sub elements of of
the SOAP Fault element, namely the faultcode, faultstring, faultactor and
detail elements. However the WSDL 1.1 standard SOAP binding explicitly
precludes
mapping any
information from an abstract fault message to a SOAP
Fault other than the
contents of the detail element. In other words there is no
standard way to
specify information in a BPEL that will eventually be
bound into the
faultcode, faultstring and faultactor elements of a SOAP
Fault element. This
specification does not provide a resolution for this
problem.
Location: I am fine with 13.4
or 11.4 Thoughts?
Here is my original text
(written independently of Yaron's text):
BPEL does not support
any way of getting or setting faultcode, faultstring or faultactor in
sending, receiving, throwing or catching a fault. The following provides
the rationale: Recall that faultcode, faultstring and fautlactor are sub
elements iof the Fault element as defined by the SOAP 1.1 standard. The
definition of a SOAP fault binding according to WSDL 1.1 specification
only provides for binding to the detail element (a sub element of the SOAP
Fault element) and not to the SOAP Fault element itself. Because a BPEL
message variable is defined via WSDL definitions, it can only contain the
content of a detail element, not faultcode, faultstring or
faultactor.
I was planning to
include it in section 13.4 (right above the start of section
13.4.1).
Here is Yaron''s
text:
Insert after the
paragraph in section 11.4 that begins "Note that the
<reply> activity
corresponding to a given request has two potential forms."
Implementer's Note:
BPEL treats faults generically, without respect to
which particular
transport they have been bound to. Normally, when
sending or receiving a
fault, a BPEL would specify generic fault
information in the
abstract fault message and then a WSDL 1.1 binding
would transform that
generic information into/from specific error
information unique to
the transport being bound to. In the case of SOAP
this would mean
providing a mapping between generic fault data and
SOAP's fault code,
fault string, fault actor and fault description
values. However the
WSDL 1.1 standard SOAP binding explicitly precludes
mapping any
information from an abstract fault message to a bound SOAP
fault other than the
fault description. In other words there is no
standard way to
specify information in a BPEL that will eventually be
bound into the fault
code, fault string and fault actor values of a SOAP
fault. This
specification does not provide a resolution for this
problem.
Best Regards,
Kartha
469-524-2639
