W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: Issue: Problem with ProcedureNotPresent fault subcode

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 3 May 2002 16:46:10 -0400
To: Jacek Kopecky <jacek@systinet.com>
Cc: moreau@crf.canon.fr, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Message-ID: <OFCC80E13C.93378564-ON85256BAE.007289F0@lotus.com>
Jacek Kopecky writes:

>>  I believe you described below the case where you 
>> recognize the QName. 

I don't think so.  See below.

>> In the other case - RPC as an application of SOAP, you 
>> just assume that what's come in is an RPC request. 
>> There's no mixing RPC with non-RPC on one endpoint then. 

I think this is the real point of confusion.  If I understand Henrik, and 
I think I agree with him, it's not SOAP's business to legislate that a 
given endpoint can't accept both RPC's and other SOAP messages.  WSDL may 
or may not go that way, but it's surely not required for SOAP. 
Furthermore, RPC is just a convention that makes certain things easy at 
the endpoint (I.e. mapping to commonly used programming languages).  There 
is no particular requirement for a responding endpoint to treat RPC's 
differently, at least in the success case. 

So the question is, what do we gain by requiring a different response for:

* I was expecting and RPC, and I didnt' recognize the QName (so I claim rpc:ProcedureNotPresent)
-vs-
* I was expecting any old SOAP message and I didn't understand the body (I 
think in this case we allow more or less arbitrary sender fault, right?).

Maybe the way to handle this is to clarify that an endpoint intending to 
intrepret a message as an RPC MAY or even SHOULD send 
rpc:ProcedureNotPresent for a mismatch on the body QName, however an RPC 
requestor MUST be prepared to deal with an arbitrary sender fault returned 
from the responder. 

In other words, an endpoint that was not expecting an RPC, or an endpoint 
that accepts both RPCs and other SOAP messages MAY return sender faults 
other than rpc:ProcedureNotPresent for an unexpected body QName. 

I agree with Henrik that this is an important restriction, and that we 
should not require separate endpoints (destination URI's) for processing 
of RPC and other SOAP message traffic.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Jacek Kopecky <jacek@systinet.com>
05/03/02 11:21 AM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     moreau@crf.canon.fr, <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
        Subject:        Re: Issue: Problem with ProcedureNotPresent fault subcode

 Noah,
 I believe you described below the case where you recognize the 
QName. In the other case - RPC as an application of SOAP, you 
just assume that what's come in is an RPC request. There's no 
mixing RPC with non-RPC on one endpoint then. So the fault is 
simple - it's supposed to be RPC but I don't recognize the method 
- ProcedureNotPresent is the fault.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 3 May 2002 noah_mendelsohn@us.ibm.com wrote:

 > The case where you do recognize the QName is easy, for the reason you 
 > state.  I think the questionnable case is:  the QName is a 
representation 
 > of the procedure name.  So a QName comes in.  Your code does the 
 > following:
 > 
 > 1) Is it one of the QNames I process as a known body document type -- 
NO
 > 2) Does it correspond to one of the methods I process as RPC - NO
 > 
 > OK, which fault do I return.
 > 
 > ------------------------------------------------------------------
 > Noah Mendelsohn                              Voice: 1-617-693-4036
 > IBM Corporation                                Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------
 > 
Received on Friday, 3 May 2002 17:03:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT