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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Re: [ws-caf] Fault message formats


+1

----- Original Message -----
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Mark Little" <mark.little@arjuna.com>; "Murray, Bryan P."
<bryan.murray@hp.com>; <ws-caf@lists.oasis-open.org>
Sent: Thursday, May 13, 2004 4:44 PM
Subject: RE: [ws-caf] Fault message formats


> My perhaps simplistic view of WS faults is that SOAP faults are mainly
> those defined in the XMLP WG and are emitted by the SOAP processor
> during the processing of SOAP header blocks. Then WSDL has in its
> operations, a provision for defining a message, in addition to input and
> output, called fault. That is a service specific fault that is defined
> as part of the "interface" of the web service, much like in a
> programming language you would have formal parameters with data types as
> a signature and for return values,  and then also have an exception type
> declared.
>
> I am not aware of a push to use SOAP faults where WSDL fault definitions
> ordinarily would be used. Moreover, that seems to me to be an
> unmotivated revision of the current convention. I would not favor this
> group being a trend setter encouraging the collapse of WS interface
> faults into SOAP processor faults...
>
>
>
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: Thursday, May 13, 2004 1:58 AM
> To: Murray, Bryan P.; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Fault message formats
>
>
> Bryan, as Jim mentioned, when the CAF specifications were first being
> written we took the approach that SOAP faults would be used to convey
> information about errors/faults that occurred from the comms. protocol
> aspect, whereas application/specification specific faults would be
> explicitly called out as messages in the specs. That was in line with
> the way in which other specifications seemed to approach things too.
>
> Are you saying that the approach of using SOAP faults to convey higher
> level specification/implementation faults is the way things are moving
> in the industry? If so, then you're right and we should re-examine this.
>
> However, as to tying to WS-BaseFaults, I think that's a really bad idea
> at this stage. For a start I have no idea where things coming from the
> WS-RF TC will fit into a WS architecture - do you think that it's going
> to be the case that all SOAP server vendors will really have to
> implement some or all of WS-RF? If we go with SOAP faults then we're in
> a pretty good place, since we can guarantee that all vendors will
> implement that. Then there's the fact that WS-RF is just starting and
> who knows that's going to happen in the next 12 months.
>
> Let's tackle one thing at a time. I would be against any tie to WS-RF at
> this stage, but as the work of that TC evolves and becomes clearer we
> can always revisit the situation. There are several things that we have
> deferred until a 1.x release, for example, and perhaps this is another
> one of them.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: "Murray, Bryan P." <bryan.murray@hp.com>
> To: <ws-caf@lists.oasis-open.org>
> Sent: Thursday, May 13, 2004 2:36 AM
> Subject: [ws-caf] Fault message formats
>
>
> > Both the 1.1 and 1.2 versions of the SOAP specification indicate that
> > "A SOAP fault is used to carry error information within a SOAP
> > message." (from SOAP 1.2). Tools and SOAP stacks are able to make use
> > this statement by having a specific place to look for or generate
> > error information. The tools and stack may be optimized for processing
>
> > faults because this is how error information is communicated.
> >
> > I suggest that it might be better if WS-Context sent error messages
> > using the SOAP Fault element rather than defining a new element for
> > transmitting fault information. Since SOAP messages are defined only
> > as something sent from a sender to a receiver, it should not matter
> > that the message gets sent in the HTTP request (for a binding to SOAP
> > over HTTP).
> >
> > Something that is less clear is how best to describe this use of fault
>
> > messages in WSDL. For an input-output binding it is clear that the
> > wsdl:fault element would be used. With the binding proposed for
> > WS-Context (is this binding normative?), it is necessary to describe
> > that the client will be receiving the fault message rather than that
> > the service will be sending the fault message. WSDL 1.1 is not clear
> > about any message flow direction implied by the use of the wsdl:fault
> > element, but I think most people understand the fault to be sent from
> > the entity described by the WSDL. WS-I does not clarify this any
> > further.
> >
> > I think it would be best not to use the wsdl:fault element to describe
>
> > the receipt of a fault message. Instead, the SOAP Fault message should
>
> > be extended for the specific WS-CAF faults and specified on the fault
> > receiver using wsdl:input. I believe most SOAP stacks will still
> > recognize the fault correctly and be able to optimize its processing
> > as done for other faults.
> >
> > Another option is to consider that many of the messages exchanged in
> > WS-Context are simply request-response message pairs. It is possible
> > for WS-Context to map those message exchanges that do represent
> > request-response pairs to operations having both an input and an
> > output message defined. For these operations, the wsdl:fault element
> > should be used to describe the faults. We would need to examine the
> > remaining messages that require an asynchronous mapping to see which
> > fault messages are defined for these cases and then decide how best to
>
> > describe these fault messages.
> >
> > I think it is important that SOAP Fault messages be used to
> > communicate fault information. I further suggest that it would be
> > prudent to define WS-Context faults such that they are compliant with
> > WS-BaseFaults.
> >
> > Comments?
> >
> > Bryan
> >
> >
>
>



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