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

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

Ok, having seen the messages from you and Jim, I think have a clearer understanding. I hadn't noticed that you were proposing multiple identifiers, which led to one lot of confusion.

 

 

But I believe you are actually proposing URLs, not URIs, which include the location-unaware URNs. There is clearly no way an application receiving a BTP Identifier of

   urn:oid:1.2.826.0.1.4982673.34.8.212 

is going to be able to work out where to send an ENROL, without a lot of standardised and deployed name->address infrastructure. There is no requirement that there be such.  But that's a valid URI. (see http://www.iana.org/assignments/urn-namespaces )  (The URIs in the link Mark gave are actually all URLs - see RFC 2396)

 

But I guess you are thinking of things like

 

  btp-soap-http-1://pluto.whosit.com/SOAP/btp/34565912:2342344:432425:24355

 

which clearly could be used.

 

 

If that's right, then I think your proposal comes down to a denormalisation of the address and identifier arrangement that there before. In our discussion in Choreology (including the implementation wing), we considered this - it does clean things up a bit, but we decided it wasn't that nice. Some of the problems:

 

     It would mean any btp carrier should be registered as a URL scheme - not essential perhaps.

 

     each BTP url scheme (registered or not) would have to state how it deconstructed into the fields used by the carrier protocol - if that thing above is going over http, does all of it go in the http url (and thus the http headers, in various ways) or is there some delimiter in it (not shown) which effectively separates the addressing bit from the identifier.

 

     if there are multiple identifiers on the original exchange (on CONTEXT and ENROL), then getting a match (e.g. which Inferior is this from) means comparing the (single) received identifier (say, on PREPARED) with all/each of the Identifiers on the ENROL. This was what was so nasty with the old scheme. This can be implemented of course. But it's messy.

 

    this gets even nastier on the Terminator:Decider interface, where we used to have the handle, precisely to avoid exposing the Terminator to the multiple identifications of the same thing. (The fact that we suspect in practice these will often be sets of one doesn't reduce the problem, since the program can't guarantee that it won't be called on to interoperate with something that has multiple addresses/identifications)

 

(the others will probably add to that list - those are the ones I remember)

 

It seemed to me that both this, and the original proposal were effectively over-loading the address element to do two things:

    disambiguate the (end-part of the) Identifier

    locate/give access to the state engine the Identifier identifies.

 

A locatable address does the first of course because it is itself globally unambiguous (at least within the globe of the interconnected machines that see the address). But it isn't essential to use a usable address, and separating the two means (as so often) that each can concentrate on their own job.

 

Making the Identifier globally unambiguous, but without routing implications means there is never any need for multiple identifers - the Identifier can in fact be unique (the only name for the thing) as well as unambiguous (only identifies one thing). It doesn't have any structure that is known or understood by anything other than its creator implementation. All you ever have to do with other peoples Identifiers is see if they are the same - and you don't need to worry about who made it, since they are all different. (they can also be quite short - UUIDs have a specified urn syntax, for example)

 

And the addresses don't need to be matched against or considered other than to work out where to send an outbound message. They could be changed to URLs, but that would really just be a syntactic change, converting the xml compound of the three parts into some btp-defined url syntax with the same parts.

 

 ....

 

<old text - outlook has mangled the quote indicators>  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. 

 

PF: It's the same for every message, except CONTEXT, CONTEXT_REPLY, so I don't think it needs describing each time. That the draft is unclear on a particular point is of course something that can (and should, and will) :-) be addressed. 

 

 

snipped the rest 'cos we were at cross-purposes.

 

Peter