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

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

This is one of three separate replies to Mark's message, though the threads
may need to remerge.

snippage at various places - usually not because I agreed though :-)

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

and if they are the same URIs, then one used to identify is also used to
locate. Which to me is confounding delivery and payload information.

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

now separate issue

> So, "aren't unambiguous" (double negative) means that you want
> addresses to
> be amiguous? Why?

I want addresses to be (potentially) ambiguous with respect to transactions
because I only want them to locate an endpoint, which is the proper role of
"delivery" information. Making them identify particular transsactions is
overloading them with "payload" information.

Whether such an "ambiguous" address is then a URL is purely a question of
syntax. Think abstract :-)

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

No, it has to be standardised, and standardised at btp level, not at binding
level. I've got to know how to do is_same_transaction() on things I receive
both for your identifiers, and for mine.

[ added later: we're not arguing for the same thing are we ?  if the URI
(actually must be a URL) used for delivery might not be the same as the
identifying URI in the payload, then they must be in separate places in the
overall message (i.e. ignoring protocol boundaries for a moment). So the one
in the payload is *never* be used for delivery, and the one (or set) in
<whereever> is only used for delivery. In which case, there's no point in
requiring either to contain the other's information at all.  Our
disagreement then comes down to whether we keep the present xml structure
for endpoint addresses, or reformat them into URLs, defining rules for
breaking the fields apart.  But you seemed to want something more different
than that (which would itself be rather pointless). ]

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

answered separately, but I meant "all the URLs in a message that is
announcing the location-identity of a transaction"

(actually, I'll mention here that these - superior, inferior, decider aren't
necessarily all "transactions" within the understanding of all
implementations. they often are, and in some implementations may always be,
but the multiple identifiers are intended to allow implementation
flexibility, and it may confuse some implementations to think of a
Participants state information as a "transaction".  But we can use
transaction as short-hand for the purposes of this discussion).

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

There's a lot of points in there

 my question was why do you force the <whatever> that identifies the
transaction to contain delivery information. The <whatever> certainly
resides in the payload. We are agreed it is globally unambiguous (which it
wasn't in 0.9.1 and earlier) - it is sufficient on its own, without
additional information to name the transaction.

but you've answered about passing information up from carrier to btp
service, which never really happened !

If that's referring to the reply, as in reply-address, then it won't be tid
anyway - there isn't a transaction at the request end of the btp
request/reply pairs. In practice, if the carrier is request/reply, there
*might* not be a reply-address, if the requestor forces the (likely)
response on carrier response. But if the underlying carrier isn't RR, then
some btp or btp-binding defined thing has got to carry the reply-address -
which is why we have reply-address as an abstract construct, and as a real
field, which can be null in particular cases. If the underlying carrier is
RR, then (at binding specification), you either force response-on-response
for all instances, or follow the rr exploitation rules, and allow (but do
not require) a non-null reply-address.

Assuming you don't want to reduce the function by chucking out the rr
exploitation for soap-http, your approach seems to require some additional
xml wrappers to hold the reply-address, so you can say that which bits of
the soap-body are btp payload, and which are deemed part of the delivery
information.

If your paragraph was referring to superior:inferior exchanges, which aren't
request/reply at btp level, then there are tid's in the messages, but they
can't, in general, be used to work out where to send the next message (the
multiple address possibility stops this working in general). Quite often,
the senders tid isn't on the message anyway (superior->inferior messages it
isn't, inf->sup it is).  Each side has to refer to the original set-of-URLs
(with your scheme) or addresses (old, and ours) it received on CONTEXT or
ENROL as may be to send a message. It may (by exploitation rules) take
advantage of a convenient response, but it can't guarantee it.

But your desire to use the tid to work out where to send the next message
seems to be precisely contrary to your requirement to separate the
transaction and carrier levels.


Peter