← Prev in month ← Prev in thread

Proposed text for issue 170 (RESEND)

From
Kartha, Neelakantan <>
Date
2005-01-11T17:53:44+00:00
ID
Thread
Proposed text for issue 170 (RESEND)
Title: Proposed text for issue 170

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
← Prev in month ← Prev in thread