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

[Alastair Green <alastair.green@choreology.com>]

Hi Jim,

I'm stealing time from some charmless administration tasks, so I will be brief,
and may inadvertently sound curt. I may also be tardy in replying to any replies
...

We discussed all of this about two weeks ago. The reasoning which resulted in
our proposal was as follows:

a) got to have globally unique transaction ids: therefore axe the old "id" and
use <address> as the id, by stating that each address must be globally unique

b) if each address in the address vector is globally unique then we can pull one
out and use it as the id

c) promulgate a rule for which address should be pulled out: obvious rule is:
the first (as it is always present, and any will do). [The scheme which says
"choose the one you're using for communication as the id" deprives us of a
reliably constant value for the id, and creates a plethora of nasty
implementation/admin problems].

d) now, replace the old id by the "first address" to avoid sending address
*vectors* all over the place

e) what is the value of the "first address"? Answer, any valid URI (need not be
a recognized carrier protocol URL, because the extensibility rules dictate that
I may receive an "address" for a protocol that the impl doesn't recognize, or
that is not specified in the spec (which specifically provides for unknown
protocols)

f) create a URI which has no relationship to any network protocol (i.e. is not a
URL) and put it in the first slot in the vector -- it will come back to me as
the transaction id (can't stop me doing this, makes my life as implementer
simpler because transaction ids are produced according to a general rule and
within a slice of the global namespace I own, like
cohesions.com/octaword-as-hexstring or a URN form as Peter suggested.

g) This is getting ridiculous: why waste our time conflating addresses with
transaction ids: just state the rule that the tid is a URI and let addresses be
addresses. The overload is confusing and unnecessary, and gives zero benefit.

Incidentally, the further away the "address-as-transaction-id" travels in the
tree, the less "address-ness" it has, and the more "id-ness" it has (this is
beginning to sound like Hegel).

Also, not all carrier protocols can be relied upon to transmit user data in the
address to the recipient, and some addresses may be malformed if they attempt to
carry user data (I suspect Java RMI fits into both these categories at once).

Therefore, you can never eliminate the need for optional addressing information,
and if you want to make an address globally unique it must be unique across
"carrier protocol address" and "optional addressing information", so ... URL
alone cannot be generally good enough to capture global uniqueness, unless it is
a special btp:// URL which we have to define, which indirects the
abstract-to-concrete mapping that must take place anyway.

Alastair


"WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote:

> Monring Peter,
>
> > I think no identifier should be expected to be resolved to
> > any endpoint by any means.
>
> So an indentifier shouldn't be used to "dereference" the thing it
> identifies. Hmm, this seems somewhat strange, maybe we could change its name
> to an "un-identifier."
>
> > No, on our scheme you would use that in a fully interoperable
> > exchange. The identifier is independent of the binding. It is
> > used only to identify the state (not the communication
> > endpoint). The address(es) define an
> > endpoint(s) where the state can be found, using the identifier.
>
> I understand this, the addressing in the current revision is very rich
> indeed and can be used to deal with a whole bunch of protocols.
>
> However I don't think we are in the game of building a protocol bridge. The
> addresses in the abstract sense will have to be concrete at some point. If
> we assume a homogeneous transport protocol then we can actually optimise
> this at the binding stage.
>
> > Don't worry about the place the address belongs to - it can
> > make its address and its logic align how it pleases.  Worry
> > about the sending side, which must take the address (our
> > scheme) or URI (your scheme) and work out what goes where in
> > what protocol.  The address above, and the rules on addresses
> > are defined as - put the additional-information in the
> > message (special rules for relatedgroup, which is treated as
> > a unit for this purpose), combine any number of messages with
> > the same binding address in a bundle; put the bundle in SOAP
> > header or body on an http request (or, defined
> > circumstances, response) in accordance with various rules.   For your
> > scheme, btp-soap-http-1 specification has got to say the
> > equivalent of all that, plus  something about splitting the
> > URI to find the http bit. (your scheme can merge
> > additional-information and identifier proper)
>
> Right, and this is where the spec is cumbersome because it does not factor
> out logistical parts of a message from the "active" BTP payload.
>
> > Yes - your approach may simplify the presentation of the
> > abstract message set, but it greatly complicates the
> > specification of the binding, including the soap/http binding
> > we are including.
>
> I don't think it does. Assuming we are designing a coordination framework
> and not a protocol bridge I think the simplification of messages is a good
> one since the bindings become one-off chunks of (hard) work, rather than a
> continuous drain on the resources of an BTP coordination service.
>
> Jim
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard