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

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

Pruning cc list. Reply is to Mark's -> Alastair -> Mark -> me -.....

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

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.

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

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.


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

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.

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

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

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. 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.  If both are no,
then there's no virtue in changing the addresses to be URIs, unless you
think

<btp:address>
  btp:soap-http-1:burble.acme.com/soap/biztran?:alpha
</btp:address>

is enormously better than

<btp:address>
  <btp:binding-name>soap-http-1</btp:binding-name>

<btp:binding-address>http://burble.acme.com/soap/biztran</btp:binding-addres
s>
  <btp:additional-information>alpha</btp:additional-information> ?
</btp:address>

(and note that, for the url, there is quite a lot of specification needed on
how to split the fields of the btp URL, given the variation of what might be
in the embedded binding address already. This is already done for the xml
constructs.)

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

Peter