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

On Sun, May 27, 2001 at 10:52:04AM -0700, Henrik Frystyk Nielsen wrote:
> 
> * 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.

Hmm...

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

OK, I was with you up until here. Without getting into a debate of
what a protocol is, and what follows from that, or getting stuck into
nesting (which still eludes me as a useful analogy for the
relationships here), this seems a bit arbitrary.

I certainly agree that SOAP itself doesn't mandate any particular
message exchange pattern. However, RPC (IMHO) is an restriction or
packaging of SOAP, to be embodied in a Module; two parties know that
the RPC convention is in use, and the semantics of the messages and
the message exchange pattern follow from that.

So, the trick is to define a convention that is useful in a broad
number of situations, doesn't overly complicate implementation, and
is easy for people to understand, so that they use it correctly.

As used in the SOAP community (AFAIK), the semantics of RPC are
request/response -- either may be empty, but the operation isn't
complete until the response is received. Allowing RPC exchanges
without a response complicates it; while there are legitimate uses of
SOAP with one-way messaging, I dispute that it's useful to include
them in the RPC convention. If we do, RPC becomes all-encompassing,
and therefore redundant.

If we don't require a response in RPC, users of the RPC convention
will need to specify whether a response is required. This will make
implementations more complicated, especially those that are
RPC-specific.

I'd propose that when the RPC convention is in use:
  - it implies a request/response application message exchange
    pattern (as opposed to transport message exchange pattern)
  - both messages are required for successful operation
  - both messages must be valid SOAP messages, and conform to any
    restriction on semantics defined in the RPC convention (but may
    use attachments, etc.)

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

I think these issues exist whether or not we require a response.
Hopefully, through Modules ;)

-- 
Mark Nottingham
http://www.mnot.net/

Received on Sunday, 27 May 2001 23:49:04 UTC