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

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

Jim sent:

>
> > > If I
> > > have a Superior, with a fail-over address, on your scheme I
> > send out
> > > two URIs in the CONTEXT. How many of these appear in the
> > PREPARED from
> > > you ? Both of them ? Or just the one you happen to have
> > used for the
> > > communication.
>
> The one that happens to be in use at the time - i.e. the one that hasn't
> failed, in the no-failure case a "preferred" URI which is defined on my
> terms.

so - that's the one you happen to have used for the communication.  So far
from separating the btp and delivery, you now have to find out how you are
going to send the message before you can determine which id you put in it.
And every entity that might have to match these (which is liable to include
either end of the Superior:Inferior - in some cases I have to match your
identifiers as well as match my own - has to match one-against-any (i.e. is
scalar A a member of set {B} ) everytime.

(An alternative, which Alastair laid out, is that one of the URLs is
nominated by standard means as the identifying one - that avoids the
set-match, but then it possible to use it for that exclusively, and ends up
at our proposal)

> > > On our scheme, the CONTEXT would contain one URI (from an arbitrary
> > > scheme of our choosing), and two addresses. The PREPARED
> > contains only
> > > the URI, however you sent it.
>
> I don't have the vaguest idea what this is proposing. It seems to suggest
> some kind of logical mapping between the URI and the addresses?
> Well why not
> just have two URIs? At least then I'm only lugging around 2 bits of data
> (the URIs) and not 3 (the URI and the 2 addresses) and I can still resolve
> entities perfectly well.

A) do understand that our use of URI is purely identification.
B) the correspondence between URI and the addresses is only that the URI
lives at (the thing it identifires is accessible at) the addresses.
C) using the URLs to both identify and locate is a kind of overloading
D) if the identification only identifies, and the addresses only locate, the
total information shipped is probably less. The addresses would (typically)
only be the general endpoint - you could use the same address on every
transaction that was run from that process (at least)

Peter