RE: [bt-spec] URIs and address-as-X (MAJOR)

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

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).
 

I think it still needs to carry the Superior address set, because otherwise there is no knowledge of where to send the ENROL (unless it happens to be appropriate to one-shot, but it isn't always). The globally unambiguous Identifier says what it is. The address set tells you where to talk to someone who knows about it.

 
3. Request_Status

Problem: Target Address, Reply Address, and target identifier all appear
here. Target address and reply address are transport issues. Target
identifier is useless without the target address.

Remedy: Target identifier becomes a URI. Reply address and target
address disappear. The request_status operation is invoked on the
endpoint described by target identifier and the reply address is
implicity assumed to be the same endpoint as the entity that issued the
message (this is easily catered for in most common transports like HTTP
and SMTP). The situation where a reply address is actually different
from the sender's address can be handled by the sender simply
redirecting replies on behalf of the real recipient.
 

Except that you shouldn't assume the target identifier describes an endpoint. It identifies a state, which is accessible at an endpoint. Otherwise, I think this is just an example of what is specified in the binding details. In practice, I would think it very unlikely that an implementation using the soap http binding would do anythng other than omit the reply address, which (in accordance with the request/response exploitation rules) forces the target actor to put the reply on the http response.

6. Request_Inferior_Statuses

Problem: Target address, reply address, target identifier, inferiors
list.

Remedy: The target and reply addresses can be delegated to the
transport. The target identifier and inferiors list should be URI-based.
 

yes, inferiors-handle isn't now needed since the inferior identifiers are globally unambiguous anyway, so inferiors-list contains URIs This is covered in the proposed solution to 77.

 

22. Redirect

Problem: The redirect message seems overly complex. The mechanism isn't
too bad per se (new addresses for the same identifiers), however it may
be possible reconcile redirection with the new URI-based philosophy.

Remedy: Ditch the new and old addresses. Instead go for a (set of?) new
superior/inferior identifiers as URIs.
 

 

Ouch. This is why it is a really bad idea to bundle location/routing/accessing information into the identifiers. The only way the Superior (say) can sort out which inferior is which is from the identifier - and now you change its name. And it's always possible for a REDIRECT to get lost, so we now get messages turning up from what appear to be entirely unknown Inferiors. With the old way of doing things, at least the identifier was unambiguous within the scope of all the addresses it might have (actually the old way was subtly broken at this point - but this would be much more broken).

 

Make the identifiers globally unambiguous and location-agnostic..  Have addresses to say where things are at the moment.

 

Issue: do alternate addresses (e.g., list of address-as-decider) contain
the primary end-point as well as the alternates, or just the alternates?
 

all of them. In practice, I expect most implementations will use a list of one. But the minority are very important.

 

 

 

Peter

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