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

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

re-ccing list.

> -----Original Message-----
> From: WEBBER,JIM (HP-UnitedKingdom,ex1) [mailto:jim_webber@hp.com]
> Sent: 30 January 2002 12:02
> To: Peter Furniss
> Subject: RE: [business-transaction] Re: [bt-spec] URIs and address-as-X
> (M AJOR)
>
>
> [Snip]
>
> > 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
> > ?
>
> Fine, that means that we need to propagate a version number with the BTP
> messages.

That assumes both protocols upgrades are back-compatible, and they may not
be. And how does the sender know that it isn't a non-soap, proprietary
binding to http ?

>           Furthermore, I can't see how having this helps either:
>
> <some address>
> <some other address>
> <yet another address>
> <identifier>823478:3904324:243</identifier>
>
> gives you anything more, unless you know a priori what protocols those
> addresses are expecting - and I'm not talking about the binding
> information
> in the messages here (which would tell you that), but in advance in the
> sense that the capability to talk to those endpoints over those protocols
> would be built into your system in advance.

because a BTP address is
  binding-name
  binding-address
  additional-information

and the binding name says what the BTP version and carrier protocol are. And
the (already written) rules say that the binding-address is of the form
understood by the carrier protocol (e.g. for soap-http-1 it is an http URL),
and the additional information is carried above the carrier protocol (and
perhaps rare with http).

> Again I repeat that we are not in the business of building a protocol
> bridge, but in the business of creating a coordination framework. Let's
> factor out this multiprotocol business to other bits of software like
> CapeConnect.

We don't mind if you restrict your implementation to web services :-)

> > "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.
>
> Given that you haven't seen the implementation, that's pretty spurious.

I was inferring from the simplifications you wanted what the restrictions
were that aligned with your implementation :-)  My point was that the
abstract message set is just that - abstract - and doesn't mean the
information is carried in a particular place in a concrete case. But the
information is carried, explicitly or implicitly between the interoperating
systems that host the btp actors in the concrete case. So it is modelled in
the abstract case. There is more than one way of modelling it in the
abstract case, of course, but that has no implications for implementation.


> > > 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).
>
> It's a request-response world. If it isn't you run into the
> half-semi-partially deaf on a Wednesday afternoon in June problem.

BTP, at abstract level, is designed to work over non-RR carriers, and more
importantly, is not RR itself (like OSI TP/CCR and TIP, unlike OTS, to its
cost, in my view). RR is useful for application developers, though not the
only useful way. It isn't necessarily desirable for an infrastructure
protocol.

> It's entirely reasonable to implement a request-response style
> protocol over
> a non-request-response infrastructure, but that's not for us to
> decide - if
> BTP messages are paired, so what?

Look at the state tables. *Some* of the BTP messages are paired. Some are
not. The issue is not an RR protocol over non-RR, but a non-RR (or partially
RR) over RR (and non-RR).

Peter