RE: Issue 16: methods with void return type and no out params

Thanks Frank for starting this,

Before diving into the details, here are a few of what I consider
(subtle) distinctions in SOAP:

* Because SOAP is a wire protocol, it doesn't really say anything about
what a method call is or how method calls are invoked (whether they
block etc.) within a particular implementation. All it really says (I
believe) is that *if* one has such a thing as a method call or a
response then this is how they can be encoded using the SOAP data model.

* The SOAP RPC convention (how to encode method calls and results) is
independent of the HTTP binding (request and response). It *may* be used
in combination with HTTP in which case HTTP provides the correlation
between requests and responses etc. but HTTP is of course also a wire
protocol that knows nothing about method invocations. I have sometimes
referred to RPC and HTTP as nested protocol bindings.

* SOAP says nothing about which guarantees the caller has for the
request to reach the other end or a response to make it all the way back
to the caller. If used in combination with HTTP then HTTP gives certain
guarantees and we know that we have a HTTP response that is either a
success or a failure.

* The RPC convention doesn't require that a RPC convention request MUST
be followed by an RPC convention response. In fact it is perfectly valid
for a caller to use the RPC convention for the request and then get back
a plain HTTP response with a GIF image, for example. Also, the current
text does not disallow not sending any SOAP response at all but simply
an empty HTTP response.

* When using HTTP, the HTTP status code determines the outcome of an
HTTP request. For example, one can imagine sending a SOAP HTTP request
that uses the RPC convention but HTTP requires authentication and sends
back a 401 Access Denied response without a SOAP response. In other
words, the caller has to be able to deal with HTTP only responses when
using the HTTP binding. A 200 Ok response code without a SOAP message
doesn't seem to be special in this regard.

* While the body element must be present in all SOAP messages, it can
indeed be empty

That is, I think there are several things we have to keep separate:

a) The implementation semantics of method invocations vs. the wire
protocol

b) The RPC convention vs. the HTTP binding

c) The delivery guarantees of messages vs. request/response message
patterns

d) The encoding of requests and responses from saying that a request
must be followed by a response using the same encoding.

>Although I can't say for sure what the "original intent" of 
>the SOAP authors was (perhaps they would be so kind as to tell 
>us), my own understanding of Section 7.1 is that they intended 
>behavior 4. This would also be the behavior I would recommend 
>for reasons expressed below.

My opinion is that if there is nothing to send back then we should not
require anything to be sent back simply because the RPC convention is
not a real protocol by itself. This is similar to the MIME
multipart/related binding which is also not a real protocol. Because one
sends a SOAP message in a MIME multipart/related in one direction
doesn't require that one has to receive a MIME multipart/related
message.

When the RPC convention is used in combination with HTTP then HTTP
provides a certain delivery service but that is a property of HTTP and
not of the RPC convention. If the RPC convention is used in combination
with other protocols then the desired level of service may be achieved
in other ways.

If we require a response to be returned then do we also have to say
whether it is synchronous or asynchronous? What if I use UDP as the
underlying protocol - do we also define the level of guarantee for the
response to reach the caller along with retry algorithms?

>SUGGESTED RESOLUTION
>The last sentence of Section 7.1 reads:
>
>"Because a result indicates success and a fault indicates 
>failure, it is an error for the method response to contain 
>both a result and a fault."
>
>I suggest replacing this sentence with the following sentences:
>
>"A SOAP RPC reply message MUST contain either a response or a 
>fault in the body. A SOAP RPC reply message MUST NOT contain 
>both a response and a fault in the body. In the case of a 
>method with a void return type and no [out] or [in,out] 
>parameters, the response MUST be empty."

Henrik

>[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x16
>[2] http://www.w3.org/TR/SOAP/#_Toc478383533
>[3] http://www.w3.org/TR/SOAP/#_Toc478383494

Received on Sunday, 27 May 2001 13:56:02 UTC