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)
You can clearly see that URI does
not tie us to a specific carrier protocol. It's "uniform" and
"universal"!
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.
Please read the specifications for URI and
URN. They are not carrier specific. Even when the web started basic browsers
supported multiple carries for URLs!!
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)
Let's get away from this wrong assumption
that URI is carrier specific. It clearly is
not.
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).
The multiple addresses was my idea and
does not get precluded by my earlier email. Please re-read it and you will see
that I specifically mention "Any others (i.e., used at the application level for
fail-over routing) replace with URIs" and it was to these REDIRECTors that I was
referring, although "application" is a relative term. What I meant was that
these addresses are over and above those needed to conduct the protocol
normally.
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 don't think the specification makes this
clear enough. I think in each message description we should segment into
carrier-specific and BTP payload (or whatever we want to call it). That way you
can look at the text and see immediately what is relevant to the actual
transaction protocol and what is not.
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).
|