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

[Mark Little <mark_little@hp.com>]

> 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

Ditto.

> We discussed all of this about two weeks ago.

That's good but it obviously doesn't preclude us discussing this in a much
wider audience.

[lots of stuff deleted.]

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

OK, this all sounds exactly like what we have been proposing for the last 2
days. Or have we missed something?

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

I think there is definitely some confusion about what we are describing. We
want a separation between BTP payload (information necessary to conduct the
transaction) and the delivery information (information necessary to deliver
the payload). Currently the specification mixes these up and this is what is
wrong in our opinion: if a BTP message/operation requires a transaction id,
for example, and that tid is now embedded in the delivery URI (for
uniqueness) then the tid *must* also occur in the payload. You are correct
in saying that if the tid was in the "delivery" information only then the
higher-level layers simply wouldn't be able to have access to it in all
circumstances.

Take a specific example: suppose the end point for some entity that
implements XAResource is identified by some CORBA reference and we decide to
embed the tid in the IOR and remove it as a parameter from all of the xaEnd
et al methods. This simply wouldn't work since the resource could not
determine which transaction it was being told to prepare/commit/rollback on
behalf of now unless it inspected its own address - not a good idea.
However, if we leave the xid in then all works well and good.

What we're saying is that replace all addresses with URIs and make the tid a
URI. If the tid needs to go in the payload in order to conduct the operation
(c.f. xaEnd) then it goes in the BTP payload as well. If it doesn't, then it
doesn't!

> Therefore, you can never eliminate the need for optional addressing
information,

And as I said yesterday, if we want additional addresses for
fail-over/redirect then they would go in the BTP payload too.

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

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250