[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] Re: [bt-spec] URIs and address-as-X (MAJOR)
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC