[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] BTP Issue 7 : SOAP RPC - 0.9.0.3 solution
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC