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

[Mark Little <mark_little@hp.com>]

> I think so. As I understand it, you are requiring that the URI used to
> identify is also used to determine the location and access path - except
> that seems to be what you don't want.

Now I'm sure you're reading something that was never written. What we are
saying is that URIs are used across the board at all levels, i.e., delivery
and payload.

> Not sure which solution you're arguing for :-) - I take it "Currently the
> specification ..." means what was in 0.9.1, which we are agreed is faulty.
> But our proposal (proposed soln issue 78)  follows "separation between BTP
> payload  and the delivery information" more strongly: we do not expect the
> identifier (tid) to have any location semantics, and the addresses aren't
> unambiguous.   The addresses take the message to where the tid's
> identification of the state can be used.

Firstly I don't believe that issue 78 does talk about the separation of
deliver from payload as we've been discussing. This is really a separate
issue, but one that needs doing no matter what we resolve to do with
addresses and identifiers: the specification should make it clear for each
message description what information is payload and what is carrier
specific.

So, "aren't unambiguous" (double negative) means that you want addresses to
be amiguous? Why? If we use URIs everywhere then we guarantee they are
unique within a specific context. I don't think we've actually said that the
URI used for delivery is actually the same as for identification within a
payload. It could be, but it need not be. That would be implementation
specific.

> but your proposal seems to be sending the whole IOR to the XAResource
entity
> just so it can crack it open again and find the tid.

That would be one implementation. Another, based on URIs, wouldn't.

> But the addressing URIs are going to have to contain all the information
> that is currently in the compound address.

Certainly depending on the specific URI interpretation.

> I'm no longer clear if you are proposing that the tid URI is also an
> addressing URI; and if *all* the addressing URIs are usable as the tid.

Not the latter, since not everything is a transaction! However, given a
transaction id, if it's a URI then I can "instantly" contact the
transaction, or at least know where it was!

> If
> the second, then there remains a nasty matching problem for someone. If
the
> second is no, then why must the tid URI do double-duty.

Because we need the separation between what is at the transaction level and
what is at the carrier level. The carrier level should be concerned *only*
with how to get a message from A to B and should not then need to pass
specific information up to the BTP service component at B in order for it to
know where to send a reply (if necessary). Everything that the service
component needs to deliver a response should be in the payload and if the
tid is a URI it gets it by default.

> > > 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.
>
> As well or instead ? (this is a repeat of the question above really).

See above.

> 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.
>
> 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'll let Jim answer this one ;-)

Mark.

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