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

["WEBBER,JIM (HP-UnitedKingdom,ex1)" <jim_webber@hp.com>]

Monring Peter,

> I think no identifier should be expected to be resolved to 
> any endpoint by any means.

So an indentifier shouldn't be used to "dereference" the thing it
identifies. Hmm, this seems somewhat strange, maybe we could change its name
to an "un-identifier."

> No, on our scheme you would use that in a fully interoperable 
> exchange. The identifier is independent of the binding. It is 
> used only to identify the state (not the communication 
> endpoint). The address(es) define an
> endpoint(s) where the state can be found, using the identifier.

I understand this, the addressing in the current revision is very rich
indeed and can be used to deal with a whole bunch of protocols.

However I don't think we are in the game of building a protocol bridge. The
addresses in the abstract sense will have to be concrete at some point. If
we assume a homogeneous transport protocol then we can actually optimise
this at the binding stage.

> Don't worry about the place the address belongs to - it can 
> make its address and its logic align how it pleases.  Worry 
> about the sending side, which must take the address (our 
> scheme) or URI (your scheme) and work out what goes where in 
> what protocol.  The address above, and the rules on addresses 
> are defined as - put the additional-information in the 
> message (special rules for relatedgroup, which is treated as 
> a unit for this purpose), combine any number of messages with 
> the same binding address in a bundle; put the bundle in SOAP 
> header or body on an http request (or, defined
> circumstances, response) in accordance with various rules.   For your
> scheme, btp-soap-http-1 specification has got to say the 
> equivalent of all that, plus  something about splitting the 
> URI to find the http bit. (your scheme can merge 
> additional-information and identifier proper)

Right, and this is where the spec is cumbersome because it does not factor
out logistical parts of a message from the "active" BTP payload.

> Yes - your approach may simplify the presentation of the 
> abstract message set, but it greatly complicates the 
> specification of the binding, including the soap/http binding 
> we are including.

I don't think it does. Assuming we are designing a coordination framework
and not a protocol bridge I think the simplification of messages is a good
one since the bindings become one-off chunks of (hard) work, rather than a
continuous drain on the resources of an BTP coordination service.

Jim