[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)
Prasad,
There are many faults that can be generated at all levels - by the many
protocols that get into play when messages are exchanged. I don't think we
want BPEL to deal with all these, but instead to focus on application level
messages. This is of course why BPEL builds on the port type of the
service, not the binding details. So I am for continuing our glorious
tradition of leaving binding gorp to the infrastructure.
The only question this discussion raises in my mind is whether we should
have a runtime fault to represent at the process level all errors
associated with remote access - something like the RMI RemoteException. But
again, I am more and more skeptical of the convenience of exposing
infrastructure errors at the process level. Workflow engines do not usually
assume that the process with deal with these; often they are handled by
dedicated engine modules or even through manual intervention.
Paco
|---------+---------------------------->
| | Prasad Yendluri |
| | <pyendluri@webmet|
| | hods.com> |
| | |
| | 01/14/2005 06:14 |
| | PM |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Satish Thatte <satisht@microsoft.com>, Francisco Curbera/Watson/IBM@IBMUS |
| cc: "Liu, Kevin" <kevin.liu@sap.com>, "Kartha, Neelakantan" <N_Kartha@stercomm.com>, |
| wsbpel-spec-edit@lists.oasis-open.org |
| Subject: RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND) |
>-------------------------------------------------------------------------------------------------------------------------------------|
Something seems to have gone wrong with my previous send on this.. Trying
again.
Apologies if you get this twice..
Prasad
-------- Original Message --------
Hi,
Just some off the top of my head ranting on this...
I think we should address headerfault in the resolution for issue 170
itself.
I mean, extend the scope of resolution of 170 to clarify that BPEL does not
address mapping from BPEL level to SOAP binding level fault specifics (such
as faultcode, faultstring etc. and *headerfaullts*). It is a WSDL and SOAP
binding level issue. At SOAP binding level wsdl:fault(s) in a
wsdl:operation get bound to soap:fault(s) and specifically to the detail
element.
A particular SOAP binding may map (parts of) wsdl:input and wsdl:output
messages to soap:headers and may also define soap:headerfault bindings.
This is mostly same as in the original issue resolution but for the bit
about soap:headerfaults (BTW, I was not proposing the exact text to put in
the spec).
This does bring up a question or two for me that would need clarity (for me
anyway :):
1. It is not necessary or possible for a WS to identify the complete set of
faults in the portType declaration. Hence a fault not defined in the
portType may be received by the port? What is the expected behavior from
BPEL level on this? How does that get propagated to BPEL level, if it does?
And how does BPEL process "catch" such faults?
2. A headerfault that is defined totally at the biding level may be
received. What is the expected behavior from BPEL level on this? How does
that get propagated to BPEL level, if it does? And how does BPEL process
"catch" such faults?
Do we need to say anything at the implementer note level if BPEL expects
these faults to be propagated to BPEL level and And how a BPEL process
"catch"es such faults if at all? <catchall> does not really solve anything
here as the process is unlikely to know how to handle these faults other
than to terminate. Had it known it would have defined a faulthandler with
proper variable (type) etc.
Regards, Prasad
-------- Original Message --------
Subj RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)
ect:
Date Fri, 14 Jan 2005 11:16:41 -0800
:
From Satish Thatte <satisht@microsoft.com>
:
To: Francisco Curbera <curbera@us.ibm.com>
CC: Liu, Kevin <kevin.liu@sap.com>, Kartha, Neelakantan
<N_Kartha@stercomm.com>, bpel spec
<wsbpel-spec-edit@lists.oasis-open.org>
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 --------
Subj RE: [wsbpel-spec-edit] Proposed text for issue 170 (RESEND)
ect:
Date Fri, 14 Jan 2005 14:04:41 -0500
:
From Francisco Curbera <curbera@us.ibm.com>
:
To: Satish Thatte <satisht@microsoft.com>
CC: Liu, Kevin <kevin.liu@sap.com>, Kartha, Neelakantan
<N_Kartha@stercomm.com>, bpel spec
<wsbpel-spec-edit@lists.oasis-open.org>
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
>---------------------------------------------------------------------------|
| From: Satish Thatte
|
| To: Francisco Curbera/Watson/IBM@IBMUS
|
| cc: "Liu, Kevin", "Kartha, Neelakantan", "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]