RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)

Title: Message

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