Title: Message
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:]
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:]
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
