OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


> > No, (our version) address == endpoint.  identifier == transaction
>
> Right, in my mind an endpoint == transaction since an address just gets me
> halfway there.

ah - this has caused some confusion, as I assumed you by endpoint you meant
the BTP actor that is going to deal with this - i.e. where the carrier hands
over to btp-specific processing. In one implementation that may indeed be
focussed on a single transaction, but in another the same thing (e.g. java
object ?) deals with lots of transactions, using some internal table for
lookup.  The existing text very explicitly leaves that to implementation
option, and, even more importantly, makes it transparent to the other side
which it has chosen. And makes it an option for all carriers too. (This was
vital in ensuring we included the implementation structure that Pal was
thinking of when he wanted "one Participant per system" (or so I
understood))

So you must distinguish endpoint and transaction (or think up a new term for
a carrier destination)or you lock everyone in to the implementation approach
you want to use.

> > it is spurious simplicity, because you have to specify the
> > rules for how to treat the different parts of your identifier
> > so that something that wants to use it to send a message
> > knows which bit to pass to its end of the carrier
> > implementation, and which bit to ignore, because it is only
> > going to be used at the destination to distinguish the
> > transaction among the several that
> > (normally) exist at that endpoint.
>
> How the URI is treated depends on the behaviour of the transport
> stack that
> you're using. Of course if you want to use raw TCP sockets then
> you'll have
> to do a lot of work yourself. If you hook into some other,
> higher-level part
> of a stack then your URI should be understood.
>
> > I'm going to try another analogy -
> >
> > posit: I wish to send a written instruction to my bank, to do
> > something with my account.  I write this on a piece of paper,
> > giving the bank sortcode and the account number. Those
> > unambiguously identify the account.
>
> OK.
>
> > There are various ways I could send this to the bank - post,
> > fax, take it into the branch. None of these affect the
> > content of the paper.  The information on the paper does not
> > tell me the postal address, fax number or branch location -
> > but that's ok, because the bank told me how to address things
> > to it by any of those means. And each means has its own
> > address format.
>
> And when you choose one of these, you must pick a binding, and at
> that point
> you must pick a concrete form of the address. For example, the fax binding
> actually does have a different address from the postal binding since they
> have different URI forms.

Now read my paragraph again see what it says. Of course the addresses are
different. But the information in the payload does not contain the
addressing information. And the binding used does not affect the
identification.

> > But note the addressing information is the same for any other
> > account I have there. If I fax them the document, they know
> > which account to change because of the identification on the
> > paper - which wasn't used in the routing at all.
>
> Not true. The addressing information is binding dependent. It may be the
> case that your bank uses the same identifier (in your sense) for each
> addressing scheme, but then again it may not.

I thought the analogy might let you see what we were trying to do, in
separating the identification and the addressing, but you keep confounding
them.  Think real banks.  If my instruction says "cancel standing order to
... from account sortcode 60-04-29, number 23459876", with appropriate
signatures etc, then the bank determine which account to work on using
sortcode and the number. It doesn't matter whether it was faxed or posted.
Of course the addressing information that was used to get the instruction
there depends one which binding I used.  But the addressing information used
for a given binding, is the same as addressing information used for the same
binding for a different account at the same bank. [ and my euro account is
at the same bank, but has a different sort-code ]



> > the addresses can also use standard means of representation
> > (i.e. not specific to banks) - so
> > fax: 020 8345 3384 is equivalent to a url for an endpoint.
>
> No, it's equivalent to one of your addresses surely?

I was assuming my understanding of "endpoint". And a URL is what the
existing scheme (unchanged by our issue 78) can use as a "binding address".

> > and the sort code and account number can be used by anyone
> > who holds it to see that two references are references to the
> > same account.(however the comparer might send a message to do
> > something to, or received a message about the account)
>
> This is a false economy. In order to see that two different-looking remote
> references actually refer to the same thing you can't just look
> at the last
> few characters and guess.

EXACTLY. Which is why we want to make it a separate field that is used for
nothing but identification and does not contain or imply addressing
information.

WE BELIEVE THE ADDRESSING FIELDS SHOULD NOT BE USED FOR IDENTIFICATION.

WE BELIEVE THE IDENTIFICATION FIELDS SHOULD NOT BE USED FOR ADDRESSING.


> > but in your scheme, the sortcode, account number and the
> > address are all run together. In this case there would be
> > three different URLs, each containing a different address.
>
> No, there would be one URI for each possible form of access to that
> endpoint. E.g., from RFC 2396:
>
> http://www.bank.com/10-11-12/12345678
> mailto:robot@bank.com?subject=sort:10-11-12,acc:12345678
>
> Or something similar.

That is exactly what I said - different URLs, each containing a different
address (because they are different carriers).

But the practical nasty that arises from your mis-modelling of the
information is that anything needing to determine if a referenced
transaction (A) is the same as another transaction (B) it already has a
reference for has got to have the full-set of URLs for A or B. If it has the
full set for B, the test is whether a received one for A is a member of {B}.

> > But they aren't the regular url's for the carriers -
> >   fax: 020 8345 3384/60-05-29/24568754
> > is not well-formed for its scheme
>
> Why? If you define a standard URI for fax transmissions and adhere to it,
> then it would be well formed.

I was postulating that there was an existing url scheme for fax numbers -
which would probably be more likely
  fax:<international phone number>
eg   fax:442083453384

without possibility of extensions, since fax machines don't have
subdirectories.  Then what I put (corrected to
fax:442083453384/60-05-29/24568754 is ill-formed, because it doesn't match
the scheme.

> > it would have to be something like
> >    bank:fax:02083453384/60-05-29:24568754
> > and define the rules for whats what, so the sender can work
> > out what to dial and what to ignore when making the fax call
>
> Erm, no. You are implying semantics at the sender's end of this
> URI. All the
> sender knows is that there is probably an entity that it wants to
> talk to at
> the end of the "pointer." The "bank:" in the above is not
> relevant since it
> is application specific and has nothing to do with transport.

Yes - there exactly are semantics at the senders end because it has to know
how to extract the carrier-specific information that it will use on its
carrier-implementation at its end from the compound
address-and-identification URL it's got. In the analogy, if the bank says I
can fax instructions to <stringunderdispute>:442083453384/60-05-29/24568754,
something must also tell me that I stop keying numbers on my fax machine at
the first /. And that is not part of the regular fax: scheme. So I need a
banking-use-of-fax scheme.

This is partly obscured in the particular case of http because the
right-hand end of the field is of local interpretation. But even that gets
back to the distinction at the top of this message - someone may not want to
put all the transaction-identifying detail in the http url, as it demands
particular implementation approaches.

But there are also sender end semantics in identifying the binding.
Reverting to the reality - It's likely in 18 months there will be at least
three btp bindings to http - btp 1.0 on soap 1.1, btp + on soap 1.2, btp 1.1
on soap + . Which one should be used if the only information you have is
  http://buying.gunandfames.com/SOAP/btp?823478:3904324:243
?

> > comparing identifications requires the comparison to be
> > against the full set of dual-purpose urls (and gets very
> > badly broken if the bank changes their fax number); or one of
> > the set is nominated for identification purposes, even if
> > different means are used for sending; or all the url's have
> > consistent syntax so the identification information can be
> > extracted. But the last two of those are actually our scheme obscured.
>
> As I said, comparing the value of a two pointers in a distributed system
> does not necessarily tell you whether the thign they both reference is the
> same.

?  That sounds like its agreeing with me.

> > bunging everything in dual-purpose UR*s is a mistake. It is
> > precisely confounding "payload" and "delivery".
>
> I fundamentally disagree here because there are two issues being
> unfortunately mixed. It just so happens that since things "live" at unique
> addresses (the thing that transports deal with) we might as well use that
> unique ID without bothering to cobble together our own just for
> the sake of
> it.
>
> Now as for the transport issues being mixed with payload. Mostly
> things like
> target and reply addresses need to be left to the transport. Sometimes IDs
> need to get propagated around, and sometimes the places things get
> transported to needs to change. Isn't it useful if I can just give the
> transport layer what I perceive as an ID (i.e. go there!) and the
> transport
> layer automatically knows what to do since to the transport the ID is
> actually a valid endpoint URI.

In other words you hide the transport information in the ID and pretend that
it isn't there except when you give it back to the transport.

"leaving target and reply to the transport" - you don't seem to have
understood the role of the abstract messages. In your implementation,
communicating with itself, I suspect they *will* be left to the transport -
the XML fields in question will be absent. But BTP is intended to be
mappable to other implementation strategies for the same carrier, and other
carriers with different characteristics.

> Seems neat enough to me.

It might be if we agreed to lock into one carrier, and always use
request/response (c.f OTS and TIP, which are closer to those patterns. Our
input to BTP was consciously in the light of those (including implementation
experience of both).

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC