OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


BY the way mail to Kartha is bouncing -- anyone know why?

-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com] 
Sent: Tuesday, January 18, 2005 3:44 PM
To: Satish Thatte
Cc: Liu, Kevin; Kartha, Neelakantan; bpel spec
Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)

I like the proposed text.

Paco


|---------+---------------------------->
|         |           "Satish Thatte"  |
|         |           <satisht@microsof|
|         |           t.com>           |
|         |                            |
|         |           01/18/2005 03:45 |
|         |           PM               |
|---------+---------------------------->
 
>-----------------------------------------------------------------------
----------------------------------------------------------------------|
  |
|
  |       To:       Francisco Curbera/Watson/IBM@IBMUS
|
  |       cc:       "Liu, Kevin" <kevin.liu@sap.com>, "Kartha,
Neelakantan" <N_Kartha@stercomm.com>, "bpel spec"
|
  |        <wsbpel-spec-edit@lists.oasis-open.org>
|
  |       Subject:  RE: [wsbpel-spec-edit] Proposed text for issue 170
(RESEND)
|
 
>-----------------------------------------------------------------------
----------------------------------------------------------------------|




OK it is even worse than I thought :-)

Paco, do you then think the text proposed by Kartha is OK then?

The text (with my editorial modifications):

Implementer's Note: WS-BPEL treats faults based on abstract operation
definitions, without reference to binding details. Normally, when
sending or receiving a fault, a WS-BPEL process only deals with the
fault
information in the abstract fault message and a WSDL 1.1 binding
is required to transform the abstract fault message data to/from
specific communication media. In the case of SOAP bindings this would
mean providing transformation between abstract fault message 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 relate the faultcode, faultstring and
faultactor sub-elements of a SOAP Fault element to data visible to a
WS-BPEL process. This specification does not provide a resolution for
this problem.

-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Saturday, January 15, 2005 10:59 AM
To: Satish Thatte
Cc: Liu, Kevin; Kartha, Neelakantan; bpel spec
Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)

The message and part attributes in both soap:header and soap:headerfault
are there for typing purposes only. They cannot relate to any of the
messages instances that an operation exchanges; in particular, you
cannot
assume that the message/part combination that a soap:headerfault element
specifies corresponds to the same instance message as the wsdl:fault
that
the operation specifies, even if their types (message/part) match a part
of
that message.  That is, message/part in soap:header and soap:headerfault
are not a mechanism to reference a part in the input/output/fault
messages
of the operation, They are a typing mechanism for the data in the
headers.

In view of that I see absolutely no point in extending the discussion in
the BPEL spec beyond Section 3.6 of WSDL 1.1.

Paco





|---------+---------------------------->
|         |           "Satish Thatte"  |
|         |           <satisht@microsof|
|         |           t.com>           |
|         |                            |
|         |           01/14/2005 02:16 |
|         |           PM               |
|---------+---------------------------->

>-----------------------------------------------------------------------
--------------------------------------------------------------|
  |
|
  |       To:       Francisco Curbera/Watson/IBM@IBMUS
|
  |       cc:       "Liu, Kevin" <kevin.liu@sap.com>, "Kartha,
Neelakantan" <N_Kartha@stercomm.com>, "bpel spec"
|
  |        <wsbpel-spec-edit@lists.oasis-open.org>
|
  |       Subject:  RE: [wsbpel-spec-edit] Proposed text for issue 170
(RESEND)                                                         |

>-----------------------------------------------------------------------
--------------------------------------------------------------|




But headers are invisible or not based on binding -- the SOAP binding
allows explicit parts to be bound to headers.  We don't see them as
headers but in theory we may have private knowledge that a certain part
of the fault message binds to the headerfault.  On the other hand
section 3.6 forbids a fault message to have more than one part.  So the
whole thing is still confusing and I was hoping the there was some
consistent message in BP10 around this.  If not, my recommendation would
be that we should take the most conservative position and only talk
about faults based on WSDL 1.1 section 3.6 and ignore the rest.

What do you think?

-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Friday, January 14, 2005 11:05 AM
To: Satish Thatte
Cc: Liu, Kevin; Kartha, Neelakantan; bpel spec
Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)

I am still unsure of what was the original issue in the call that
motivated
this discussion but I agree with your statement below. IMO BPEL cannot
access anything but content of the soap:detail field in a fault that is
generated when the body is processed, and in fact only when that that
detail field is associated with a wsdl:fault message in the
corresponding
operation (BP10 allows faults other than those indicated by wsdl:fault
but
I don't think they fit in BPEL since all reply messages need to be
associated with a wsld operation). As for wsdl specified headers and
associated header faults, the resolution of issue 77 implies that we
consider those headers invisible at the BPEL level (I understand that is
the current situation), so the case in which the fault detail is not
used
(because the details go in a header, possibly with a different element)
is
something out of scope for BPEL.

Paco




|---------+---------------------------->
|         |           "Satish Thatte"  |
|         |           <satisht@microsof|
|         |           t.com>           |
|         |                            |
|         |           01/14/2005 01:07 |
|         |           PM               |
|---------+---------------------------->

>-----------------------------------------------------------------------
--------------------------------------------------------------|
  |
|
  |       To:       Francisco Curbera/Watson/IBM@IBMUS
|
  |       cc:       "Liu, Kevin" <kevin.liu@sap.com>, "Kartha,
Neelakantan" <N_Kartha@stercomm.com>, "bpel spec"
|
  |        <wsbpel-spec-edit@lists.oasis-open.org>
|
  |       Subject:  RE: [wsbpel-spec-edit] Proposed text for issue 170
(RESEND)                                                         |

>-----------------------------------------------------------------------
--------------------------------------------------------------|




So what is your overall recommendation for this issue?  It seems that
you agree BPEL cannot have access to faultcode etc.  Then a BPEL fault
can propagate its fault data only inside the detail element.  Is that
correct?

-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Friday, January 14, 2005 7:58 AM
To: Satish Thatte
Cc: Liu, Kevin; Kartha, Neelakantan; bpel spec
Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)

This is my interpretation of this problem as I understand it (since I
missed the editors call this week I am not sure I have the complete
context
of the discussion). I hope it helps.

Summary:

The wsdl:fault message only describes contents of the Detail element in
a
fault; however, the Detail element cannot be used for header-generated
faults; in that case the soap:fault that is generated goes in the body
but
contains no soap:detail element. The detail information is included in
the
header specified by the wsdl-soap:headerfault element, if present. The
element that specifies this information is determined by the message
definition named by the wsdl-soap:headerfault element. BP 1.0 also
allows
detail to be provided when the wsdl description does not specify it (in
a
wsdl-soap:fault or wsdl-soap:headerfault binding element).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]