"This specification does not provide a resolution for this problem."
I assume the problem is the inability to set/get the
faultcode/string/actor of a SOAP 1.1. fault message to/from a BPEL
message variable. Since SOAP 1.1 requires the data, since BPEL has no
way of specifying what data to use, the problem could also be that a
process has no way of sending fault messages using SOAP 1.1. Shouldn't
we clarify by stating that how these values are set is undefined?
Assaf
Kartha, Neelakantan wrote:
> 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
>
