- 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
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 UTC