[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] URIs and address-as-X (MAJOR)
More
detail:
Compared to 0.9.1.1 (i.e. including proposed
solutions for 78 and 77),
similarities seem to be:
a) make
identifiers globally unambiguous
b) drop
indentifier-handles, using identifiers to distinguish the Inferiors of a
Decider
differences seem to be
c)
including addressing/location information in the
identifiers
d) different way
of expressing the destination and origin of messages
e) dropping the
possiblity of binding to alternative carrier protocols
I'm
not sure that e) was intended by Mark, it would defintely be the effect (and a
very bad one, in our view)
Proposed solution on 78 understood that the URI
has *no* necessary implication for where the transaction is. If its a URN (which
would be legitimate, and useful), then there may be no way to work out the
location. (e.g. one could have an identifier that was
urn:uuid:2132cbae-378127abef23-328371897-136781267 - which is very easy to
construct, but doesn't correspond to anywhere). One could use a url of
course - http://www.furniss.co.uk/btptest/abd123123
can be guaranteed unique, but it won't get you anywhere. Making
the identifiers URLs that do imply locations mean that you can't
switch them about. (it does make them globally unambigous, since the
network location (domain name) will be unambiguous) . But then you are
locked into a single carrier (binding), since there's no way to say which one to
use.
From
the beginning, we've carefully made BTP be flexible about the carrier, which,
among other things, means that the abstract messages deal in target and
reply addresses which, in a particular case, may not actually have any existence
inside the btp messages, because all their semantic has moved into the carrier
protocol.
A very
important part of this is that BTP is not itself (as a whole) a
request/response protocol, and does not require its carrier to be a
request/response protocol. Some BTP message pairs, and many plausible carriers
in fact are, and the "request/response exploitation rules" allow use of rr where
it fits. This explcitly includes the dropping of reply-addresses where the
sender wants to force the reply (when there is one) to come back on the carrier
response. (the reply-address is still there in abstract, just it has got mapped
to the carrier's response destination)
Also
(and my recollection is this was at least partly Mark's idea), we have the
mechanisms for multiple addresses and redirection, so btp actors can find where
the other side's state has gone to when the owning process migrates or recovers,
and (by the multiple addresses) offer alternate carrier protocols (e.g. boring
old standard carrier, nice optimised proprietary special if talking to same
implementation).
Target
addresses appear in the abstract messages as a way of saying where the thing is
going, reply addresses of where a responding message is to go to. Before it hits
the wire, the target address gets broken up - the binding name decides which
carrier is being used, the binding address gets used by the carrier protocol
engine (e.g., with http, it gets partly used to setup/choose the tcp connection,
and divided again, by http rules and scattered around http header fields).
The target additional information field, which will often be absent in practice,
is the only bit that gets put in the btp message - and doing so allows receiving
implementations to do various tricks with internal routing etc., invisible to
the sender. (pretty much essential to the one-wire behaviour in fact).
Apart form that, the target address is in the abstract message precisely
because it is delegated to the carrier binding.
I was
going to reply tothe comments on each message, but it got repetitious, so
I've only commented where there are particular points:
1. Context
Problem: The transaction here is uniquely identified by a "set of BTP addresses" and superior identifier. This is way too complex and in my mind breaks encapsulation since I don't actually care that this transaction is present at/managed by by a number of BTP superior addresses. Remedy: Remove Superior Identifier and Superior Addresses, replace with URIs (which at the back-end may well map onto a number of places where the transaction can be managed).
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC