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

Mark Nottingham wrote:
> 
> On Sun, May 27, 2001 at 10:52:04AM -0700, Henrik Frystyk Nielsen wrote:
<snip/>
> 
> 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 ;)

While I certainly concur that a response (even if empty/void/null)
should be received by the initiator (request) of an RPC before
it is considered to be complete. Since there is nothing in the message 
that identifies the message as following either the one-way or RPC
convention,
how is a generic SOAP processor (designed to support both RPC and
one-way message semantics) supposed to figure out how it is
supposed to handle the message?

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