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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Re: [ebxml-msg] Comments on the 1.09 about Error Handling


After long discussions with Cliff Collins about this note and later
re-reading the specification, I've come to the conclusion this note goes
beyond our purview.  It attempts to recommend the behaviour of a SOAP
processor (possibly in a way that makes interoperability more difficult for
the sender).  While a soap:Fault element has problems on its own (lack of
context in particular), we can't recommend MSH handling of a problem
detected by the SOAP processor.  We should recognise an MSH is likely to be
implemented on top of a SOAP processor and leave it to the XMLp working
group to "fix" soap:Fault.

In our document, we should be removing requirements for the MSH to cause
soap:Fault handling.  The mustUnderstand faults when a receiving MSH doesn't
support the Message Status or Ping/Pong services are particularly poor.  We
should use ebXML error handling whenever the ebXML handler is successfully
invoked.  That probably leaves out errors in the outermost envelope,
problems with other SOAP extensions and inability to dispatch to the ebXML
handler.  Note: "errors in the outermost envelope" is not as comprehensive
as the requirement in section 1.3.6 that "all MIME errors" be reported using
soap:Fault.  I'd soften that section to remind a sending MSH that the
receiving MSH might be layered on a compliant SOAP processor and thus it
should expect soap:Fault for some errors.

An example: The SOAP processor checks the outermost envelope and passes
things over to the handler for the ebXML-msh namespace.  That handler does
additional unwinding of the (multipart) payload wrappers and encounters a
problem in that MIME information.  The handler has the context to return an
ErrorList and MessageHeader.  If it's required to return a soap:Fault (as it
is today), the sending MSH may learn only that there was some problem
because that element will be handled by the sending SOAP processor layer.
It doesn't really matter whether or not the MessageHeader and ErrorList
elements are returned along with the soap:Fault.

By the way, my other problem with the note below is that it seems to
recommend adding a soap:Fault to error messages that would otherwise contain
the useful MessageHeader and ErrorList elements, reducing their utility.

A few other problems with error handling:
* I have seen no discussion of the inconsistent error handling the document
requires (raised in my
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00242.html email).
We need to choose between NotSupported and Inconsistent when we describe
errors such as rejecting a request for a signed acknowledgment.  We also
need to describe these errors much better and make the distinction clear.

* Nobody has responded to my "More on errors" email
(http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00243.html) which
described how the current text prevents anyone adding private error codes.

* B.2.4 requires all SOAP:Fault errors to be returned separately from the
initial HTTP exchange if operating in an asynchronous mode.  This goes
beyond our purview and impinges on the workings of the SOAP processor.

thanx,
    doug

----- Original Message -----
From: "SHIMAMURA Masayoshi" <shima.masa@jp.fujitsu.com>
To: <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, 29 November 2001 01:25
Subject: [ebxml-msg] Comments on the 1.09 about Error Handling


Please add the note about SOAP Fault, Doug Bunting proposed. It is
important for interoperability.

> Date: Fri, 16 Nov 2001 10:24:08 -0500
> From: Christopher Ferris <chris.ferris@sun.com>
> Subject: Re: Fw: [ebxml-msg] Re: SOAP Fault location
> To: Doug Bunting <dougb62@yahoo.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Message-id: <3BF52F98.9080007@sun.com>
>
> +1, we cannot mandate what happens at the SOAP processor level.
>
> Doug Bunting wrote:
>
>     How about a non-normative note:
>
>         Note: A SOAP Fault element on its own may not provide the
>         requesting MSH with the context necessary to identify the
>         message in error.  An MSH returning a SOAP Fault should include
>         ebXML MessageHeader and ErrorList SOAP extensions in the same
>         SOAP message.  This would be especially useful when the error is
>         returned asynchronously.
>
>     We can't require this because we can't mandate what errors are
>     caught by the SOAP processor prior to invocation of the ebXML
>     handler.
>
>     does this help?
>       doug


Regards,

--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC