[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] BTP Issue 7 : SOAP RPC
Binding specifications for
carrier protocols that have a request/response mechanism need to state what
rules apply to the carriage of BTP messages. The following rules may be
referenced by bindings, as the “flexible request/response use” rules. These rules do not determine how the BTP
messages are carried within the request or response message, only the
considerations for which messages can be so carried. A binding may define other
rules – e.g. constraining all BTP messages to be carried on the
requests.
NOTE -- These
“flexible request/response rules”, where possible, treat the exchange of carrier
protocol request and response just as opportunities to send messages to the
appropriate destination, without regard to how any prior message was received.
However, this is only possible where both parties in a relationship can received
carrier protocol requests. Thus an implementation can ensure all replies to its
BTP messages are returned on the carrier response to its requests by not
providing an address for receiving carrier protocol requests.
Messages sent between
Superior and Inferior are not, in general, of a request/response nature. Those
between Terminator and Decider generally are of a request/response
nature.
A
BTP actor may
compound one or more BTP messages that have the same binding address for their
target in a single btp:messages and transmit this btp:messages element on a
carrier protocol request. There is no restriction on which combinations of
messages may be so compounded, other than that they have the same binding
address, and that this binding address is usable as the destination of a carrier
protocol request.
A
BTP actor that has received a carrier protocol request to which it has not yet
responded, and which has one or more BTP messages whose binding address for the
target matches the origin of the carrier request may
compound such BTP messages in a single btp:messages element and transmit that on
the carrier protocol response.
A
BTP actor that has received, on a carrier protocol request, one or more BTP
messages that require a BTP response and for which no reply address was
supplied, must
compound the responding BTP messages in a btp:messages element and transmit this
element on the carrier protocol response to the request that carried the BTP
request.
Where
only one message is to be sent, it shall still be contained within a
btp:messages element, as a “compound” of one
element.
A
BTP actor that receives a carrier protocol request carrying BTP messages that do
have a reply address, or which initiate processing that produces BTP messages
whose target binding address matches the origin of the request, may freely
choose whether to use the carrier protocol response for the replies, or to send
back an empty carrier protocol response, and send the BTP replies in a carrier
protocol request. The characteristics of an “empty carrier protocol response”
shall be stated in the particular binding
specification.
A BTP actor that sends BTP messages on a carrier protocol request must be able to accept returning BTP messages on the corresponding carrier protocol response and, if the actor has offered an address on which it will receive carrier requests, must be able to accept “replying” BTP messages on a carrier protocol request.
In the SOAP binding definition, change the two "mapping to ..." sections to :
Mapping for BTP messages
(unrelated): The
“flexible request/response use” rules shall be used. When BTP messages are sent
on
an HTTP request which is not also carrying an application message, the messages
are contained in a btp:messages element which is the immediate child element of
a btp:transmission or btp:transmissionResponse element which is the immediate
child element of the SOAP-Body. If the HTTP message is an HTTP request, a
btp:transmission element shall be used; if an HTTP response, a
btp:transmissionResponse shall be used. In either
case, there shall be precisely one btp:messages element.
An “empty carrier protocol response”
(i.e. a response with no BTP or application messages, to be sent when the BTP
actor wishes to just reply at the lower level) shall be any
of:
a)
an
empty HTTP response
b)
an
HTTP response containing an empty
SOAP-Envelope
c)
an
HTTP response containing a SOAP-Envelope containing a btp:transmissionResponse
element containing a single, empty btp:messages
element.
The receiver (the initial sender of
the HTTP request) shall treat these in the same way – they have no effect on the
BTP sequence (other than indicating that the earlier sending did not cause a
communication failure.)
Note – The transmission
and transmissionResponse elements allows implementations to treat the
transmission of BTP messages (when no application message is present) as either
a SOAP “rpc” invocation, or as a SOAP “document” (literal) transfer.
Implementations that take opposite approaches can interwork directly and freely.
As an RPC invocation, a method called “transmission” is invoked, with one
argument (the btp:messages), and an optional return value (btp:messages). As a
document transfer, the btp:transmission and btp:transmission-response wrappers
do not imply any semantics.
If an application
message is being sent at the same time, the mapping for related messages shall
be used, as if the BTP messages were related to the application message. (There
is no ambiguity in whether the BTP messages are related, because only CONTEXT
can be related to an application
message.)
Mapping for BTP messages related to
application messages: All BTP messages sent with an application message,
whether related to the application message or not, shall be sent in a single
btp:messages element in the SOAP:Header. There shall be precisely one
btp:messages element in the SOAP:Header. The “flexible request/response use”
rules shall apply to the BTP messages carried in the SOAP:Header, as if they had
been carried in a SOAP:Body, unrelated to an application message, sent to the
same binding address.
Note – The specification of the
application exchange will determine whether an RPC or document approach is
used.
Mapping for
BTP messages (unrelated):
The
“flexible request/response use” rules shall be used. When BTP messages are sent
on
an HTTP request which is not also carrying an application message, the messages
are contained in a btp:messages element which is the immediate child element of
a btp:transmission or btp:transmissionResponse element which is the immediate
child element of the SOAP-Body. If the HTTP message is an HTTP request, a
btp:transmission element shall be used; if an HTTP response, a
btp:transmissionResponse shall be used. In either case, there
shall be precisely one btp:messages element.
An “empty carrier protocol response” (i.e. a response with no BTP
or application messages, to be sent when the BTP actor wishes to just reply at
the lower level) shall be any of:
a)
an
empty HTTP response
b)
an
HTTP response containing an empty
SOAP-Envelope
c)
an
HTTP response containing a SOAP-Envelope containing a btp:transmissionResponse
element containing a single, empty btp:messages
element.
The receiver (the initial sender of the HTTP request) shall treat
these in the same way – they have no effect on the BTP sequence (other than
indicating that the earlier sending did not cause a communication
failure.)
Note – The transmission and transmissionResponse elements allows implementations to treat the
transmission of BTP messages (when no application message is present) as either
a SOAP “rpc” invocation, or as a SOAP “document” (literal) transfer.
Implementations that take opposite approaches can interwork directly and freely.
As an RPC invocation, a method called “transmission” is invoked, with one
argument (the btp:messages), and an optional return value (btp:messages). As a
document transfer, the btp:transmission and btp:transmission-response wrappers
do not imply any semantics.
If an application message is being sent at the same time, the
mapping for related messages shall be used, as if the BTP messages were related
to the application message. (There is no ambiguity in whether the BTP messages
are related, because only CONTEXT can be related to an application
message.)
Mapping for
BTP messages related to application messages:
All
BTP messages sent with an application message, whether related to the
application message or not, shall be sent in a single btp:messages element in
the SOAP:Header. There shall be precisely one btp:messages element in the
SOAP:Header. The “flexible request/response use” rules shall apply to the BTP
messages carried in the SOAP:Header, as if they had been carried in a SOAP:Body,
unrelated to an application message, sent to the same binding
address.
Note – The specification of the application exchange will
determine whether an RPC or document approach is
used.
Peter
--------------------------------------------
Peter
Furniss
email: peter@furniss.co.uk <--- note change (1 Nov
2001)
web: http://www.furniss.co.uk
phone (work): +44 20 7670
1783
phone (home): +44 20 8460 8553
phone (mobile): 07951 536168
58
Alexandra Crescent, Bromley, Kent BR1 4EX
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC