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

I have been asked by the WG to seed discussion on issue 16 from the issues
list [1].

Bryan Murray, the author of  issue 16, asserts that Section 7.1 of the SOAP
spec [2] does not explicitly state how a method with a void return type and
no out parameters should be mapped onto the SOAP protocol. Bryan conceives
of four possible behaviors:

1.      return HTTP 204 No Response
2.      return an empty SOAP Envelope
3.      return an empty SOAP Body
4.      return an empty SOAP method response

I agree with Bryan that Section 7.1, as written, is susceptible of different
interpretations with respect to this issue. I also agree with Bryan's
suggestion that Section 7.1 should be rewritten to define the minimal
accepted response for this type of method invocation. The only question,
then, is which behavior(s) should be specified.

First off, it should be stated that behavior 2 doesn't seem to be an option.
Section 4 of the SOAP spec [3] states:

"A SOAP message is an XML document that consists of a mandatory SOAP
envelope, an optional SOAP header, and a mandatory SOAP body."

Thus, if there is an envelope (a payload), it must contain a body.

That leaves behaviors 1, 3, and 4 as possibilities.

Now, the semantics of RPC are blocking: the sender of the RPC request blocks
until it receives a reply. (At the very least, the sender maintains some
"request pending" state somewhere until it receives a reply.) So, at a
minimum, some status code (explicit or implicit) must be sent back at the
transport level to unblock the sender and to indicate the success or failure
of the RPC (behavior 1). The issue is whether the transport layer message
should instead contain an XMLP payload indicating the status of the RPC
(behaviors 3 and 4), and if so, what the form of that payload should be
(behavior 3 or 4).

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.

[NOTE: In the conference call I said I would not make a recommendation.
Well, I changed my mind. Of course, my recommendation should be considered a
strawman designed to seed discussion.]

IMHO, there are two orthogonal issues:

1.)     How should the out parameters of a method be mapped onto the SOAP
protocol?
2.)     How should the return type of a method be mapped onto the SOAP
protocol?

These two issues are orthogonal because the question of whether a method
does or does not have out parameters is independent of the return type of
the method. Consider, for example, the following 2 methods:

void M1([out] int* p1);
void M2();

In both cases, the return type of the method is void, yet M1 has one out
parameter whereas M2 has none.

Given the orthogonality of these two issues, the question that must be
answered is:

Should methods with void return type always be handled in the same way or
should they be handled differently depending on different circumstances (for
example, whether the method does or does not have out parameters, or whether
items need to be returned in the header, or whether items besides the
response need to be returned inside the body)?

IMO, methods with void return type should always be handled in the same way.
If we adopt this principle, it would follow that:

Since M1 requires a SOAP method response (containing one element), M2 should
also require a SOAP method response (an empty one).

If we accept this line of reasoning, then we must accept behavior 4.

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

Frank DeRose
TIBCO Software Inc.
3165 Porter Dr
Palo Alto, CA 94303
650-846-5570 (vox)
650-846-1267 (fax)
frankd@tibco.com
www.tibco.com

[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