[bt-spec] one-wire, one-shot, compounding and target addresses

[Peter Furniss <peter.furniss@choreology.com>]

I'd welcome comments on this:

In concentrating on the superior:inferior relationship and discussing
exactly what is in the addressing fields with my colleagues who are
implementing, I think I have some clear and workable answers, especially
relating to one-shot and one-wire cases.  Text below covers this, as a
general section on compounding - this is currently in the abstract message
section (slightly to my surprise - when I was thinking about it I thought it
might get relegated to the bindings). I'm not sure that all of it belongs
where it is though.

Key surprise is that bundled and related messages always have the same
binding address - otherwise the sender won't know that it can or should
compound them. This comes out quite simply for one-wire - though the
implication is that the relay has to rewrite addresses in outbound
messages - but that seems quite reasonable, if you think what it's doing.
(if anyone else knows what yellow-book transport service was, they will
remember this isn't new).  For one-shot, it seems to be inevitable too - the
only alternative would require some special shared knowledge between sender
(inferior) and (superior) relay.

So, as discussed in some of the email and phone exchanges of the last few
weeks, the binding address of a target address is used entirely by the lower
layer (which includes any kind of webserver internal routing to get to the
right bit of code), and the "additional information" is contained in each
btp message.  There isn't any "additional information" in the xml bundling
construct "btp:messages", because that is opened and interpreted by the
first btp-understanding entity, and it is assumed to relay anything in it,
if their additional-information tell it to (but remember it created that
additional-info in the first place (that is possibly contrary to some
earlier assumptions - there had been thought of the sender constructing
additional-information, but I don't think it can do that without some
further shared understanding (which might apply for particular bindings, but
not in general, and not with the soap ones)))

Here is the draft text as in 0.79

Peter




Compounding messages

BTP messages may be sent in combination with each other, or with other
(application) messages. There are two cases:

a)	Sending the messages together has semantic significance. One message is
said to be “related to” the other.
b)	Sending of the messages has no semantic significance, but is merely a
convenience or optimisation. This is termed “bundling”.

In both cases the messages will have the same binding address, but may have
different “additional information” values. Unless constrained by the
binding, any messages that are to be sent to the same binding address may be
bundled – the fact that the binding addresses are the same is a necessary
and sufficient condition for the sender to determine that the messages can
be bundled.

A particular and important case of related messages is where a BTP CONTEXT
message is sent related to an application message. In this case, the target
of the application message defines the destination of the CONTEXT message.
The receiving implementation may in fact remove the CONTEXT before
delivering the application message to the application (Service) proper, but
from the perspective of the sender, the two are sent to the same place.
The compounding mechanisms, and the multi-part address structures, support
the “one-wire” and “one-shot” communication patterns.

In “one-wire”, all message exchanges between two sides of a
Superior:Inferior relationship, including the associated application
messages, pass via the same “endpoints”. These “endpoints” may in fact be
relays, routing messages on to particular actors within their domain. The
onward routing will require some further addressing, but this has to be
opaque to the sender. This can be achieved if the relaying endpoint ensures
that all addresses for actors in its domain have the relays address as their
binding address, and any routing information it will need in its own domain
is placed in the additional information. (This may involve the relay
changing addresses in messages as they pass through it on the way out). On
receiving a message, it determines the within-domain destination from the
received additional information (which is thus rewritten) and forwards the
message appropriately. The sender is unaware of this, and merely sees
addresses with the same binding address, which it is permitted to bundle.
The content of the “additional information” is matter only for the relay –
it could put an entire BTP address in there, or other implementation-defined
information. Note that a quite different one-wire implementation can be
constructed where there is no relaying, but the receiving entity effectively
performs all roles, using the received identifiers to locate the appropriate
state.

“One-shot” communication concerns the bundling of application messages,
especially where the application uses a request/response paradigm. The
application request is sent with a related CONTEXT message. The application
response is sent with a related CONTEXT_REPLY/related, with an
ENROL/no-rsp-req message  and a bundled PREPARED message (assuming the
operations succeeded and the Inferior has decided to be prepared). The
target address of the ENROL and PREPARED (the Superior address) must have a
binding address that is the same as the target address of the application
response (i.e. the reply address for the client, as perceived by the
Service) – otherwise the Service cannot determine that is should bundle the
messages together. One-shot is thus a specialisation of one-wire.

With “one-shot”, if there are multiple Inferiors created as a result of a
single application message, there is an ENROL and PREPARED message for each
sent with the application response and the CONTEXT_REPLY. If an operation
fails, a CANCELLED message can be sent with the response instead of a
PREPARED. If subsequent messages to the same Service, with the same related
CONTEXT, have their associated operations put under the control of the same
Inferior, only a CONTEXT_REPLY/completed is sent back with the response (if
the new operations fail, it will be necessary to send back
CONTEXT_REPLY/repudiated, or send CANCELLED).




Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX