[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
1. Section 3.6 of WSDL 1.1 makes clear that for regular SOAP faults (as
specified by the wsdl-soap:fault) the wsdl:fault message provides the
contents of the soap:detail. The it goes on to say:
"The optional headerfault elements which appear inside soap:header and have
the same syntax as soap:header) allows specification of the header type(s)
that are used to transmit error information pertaining to the header
defined by the soap:header. The SOAP specification states that errors
pertaining to headers must be returned in headers, and this mechanism
allows specification of the format of such headers."
The last sentence is however a bit inaccurate (:-( ) since all that Section
4.4 of the SOAP 1.1 spec says is that fault detail pertaining to header
generated faults should appear in the header - it does not preclude a
soap:fault from being sent, just that it may not have a soap:detail
element; the absence of soap:detail is used to indicate that fault was not
related to the processing of the soap:body. Whatever detail needs to be
sent goes in a header. Nothing implies that the soap:detail element should
be used there. See next.
2. SOAP 1.1 in Section 4.4.
"The detail element is intended for carrying application specific error
information related to the Body element. It MUST be present if the contents
of the Body element could not be successfully processed. It MUST NOT be
used to carry information about error information belonging to header
entries. Detailed error information belonging to header entries MUST be
carried within header entries.
The absence of the detail element in the Fault element indicates that the
fault is not related to processing of the Body element. This can be used to
distinguish whether the Body element was processed or not in case of a
fault situation."
4. For example, the BP10 explicitly recommends that a soap:fault (within
the soap:body) to be sent back in some cases when the error is generated by
header processing:
"R1027 A RECEIVER MUST generate a "soap:MustUnderstand" fault when a
message contains a mandatory header block (i.e., one that has a
soap:mustUnderstand attribute with the value "1") targeted at the receiver
(via soap:actor) that the receiver does not understand."
[ 3. On a different note, observe also that the BP10 recommends not
tinkering with faultcodes:
R1004 When a MESSAGE contains a faultcode element the content of that
element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace
qualified fault code ]
|---------+---------------------------->
| | "Satish Thatte" |
| | <satisht@microsof|
| | t.com> |
| | |
| | 01/13/2005 05:48 |
| | PM |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "Liu, Kevin" <kevin.liu@sap.com>, "Kartha, Neelakantan" <N_Kartha@stercomm.com>, "bpel spec" |
| <wsbpel-spec-edit@lists.oasis-open.org> |
| cc: Francisco Curbera/Watson/IBM@IBMUS |
| Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND) |
>-------------------------------------------------------------------------------------------------------------------------------------|
I still persist in hoping that we are misreading section 3.6 of the WSDL
spec. It is admittedly not super clear. Paco, any thoughts on whether the
mention of the Detail element is as narrowly binding as we seem to be
interpreting here. The inconsistency with headerfault is making me wonder.
From: Liu, Kevin [mailto:kevin.liu@sap.com]
Sent: Thursday, January 13, 2005 10:32 AM
To: Satish Thatte; Kartha, Neelakantan; bpel spec
Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)
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.
[Satish Thatte] ?? The SOAP fault elements are indeed in the standard SOAP
envelop namespace. But of course one can define a message part with the
whole SOAP-ENV:Fault GED as the element specification.
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:satisht@microsoft.com]
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:kevin.liu@sap.com]
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:N_Kartha@stercomm.com]
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:N_Kartha@stercomm.com]
Sent: Friday, December 03, 2004 1:20 PM
To: bpel spec
Cc: Satish Thatte; ygoland@bea.com
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
n_kartha@stercomm.com
469-524-2639
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]