This
issue was discussed extensively at the f-t-f. There are really several
sub-threads, all arising from issue 7, though not always obviously. Following
attempts to explain/justify what is in 0.9.0.3 in the light of the f-t-f
discussion.
The
original issue description was "Existing SOAP binding does not allow for use of SOAP RPC model, which
is inefficient, and makes it hard to construct thin clients without listening
capacity, using standard SOAP programming
toolkits."
One of the
motivations was the perceived "inefficiency", which referred to the belief
that using the document/literal SOAP model on HTTP (for btp-only exchanges) it
would not be possible to use the HTTP response for carrying btp messages. This
is not true, but there do need to be rules for when the response is used (i.e.
when can one side use it, when must the other side expect it).
0.9.0.3 provides
rules for when btp messages can be sent on an http response, and when it can
elect to send the message on an http request of its own. Rather than make
these specific to the soap/http bindings, the rules are defined generally for
any request/response carrier protocol and then referenced in the particular
binding specification. These are the "request/response exploitation rules", on
pages 108 - 110.
In relation to SOAP RPC in partiuclar,
0.9.0.3 includes (from the London messasging f-t-f, inter alia) an extra layer
of element wrapping that makes a SOAP-RPC look like a document/literral
sending and vice versa. Much discussion in Liberty Corner was on
whether this affected the encoding - it doesn't, BTP is always in line with
SOAP encoding. The btp:transmission and btp:transmissionResponse are just
tricks, used explicitly when sending/receiving according to the document
convention, to make the messages look like an RPC invocation or response. And
to implement using an RPC toolkit with a method "transmission". (this has then
to do a fan-out to process whatever the message or messages are both the
invocation/request, and on the reply, which might be carrying more or less any
message(s)).
The question is whether this is needed at
all - people seemed to have gone off SOAP RPC. However, remember that
this is a mapping to SOAP 1.1, targetting what is deployed and available, not
might (or even probably) -will-be's.
The SOAP RPC specific changes are only the
last sentence added to the first paragraph of the SOAP Binding definition:
" In the former case, an additional XML
wrapper element is used to allow implementations to treat the SOAP messages as
using the RPC convention, or to use the document
convention "
and the
paragraph
When
BTP messages are sent on an HTTP request which is not carrying an application message, the
messages are contained in a single btp:messages element which is the immediate
child element of a btp:transmission element which is the immediate child
element of the SOAP-Body element. When BTP messages are sent on an HTTP
response that is the reply to an HTTP request containing (in the SOAP-Body) a
btp:transmission element, the BTP
messages are contained in a single btp:messages element which is the immediate
child element of a btp:transmissionResponse element which is the immediate
child element of the SOAP-Body
element.
The other changes in the SOAP
Binding down as far as the note (line 3878) arise from the Request/response
exploitation rules,which are still valid whether or not the btp:transmission
stuff is done. (the other changes relate to issue
83)
There are thus three sub-issues from this that should
be considered distinctly:
a) are the request/response exploitation rules the
way to define the use of request/response
b) do they work for SOAP/HTTP in document
mode
c) do we want the btp:transmission
rpc-or-document as you please element ?
Peter