[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: a second aspect of : RE: [bt-spec] URIs and address-as-X (MAJOR)
|
Going
back to the origin of this thread, I think there may be two
issues:
A) how
to use address and identifers to distinguish and locate the entities involved in
a BTP relationship.
B) How
the abstract message definition (and other bits) should represent the
destinations of messages that will map to request/response carrier exchanges in
a web services environment.
More
or less all the discussion has been on A, but Mark's original message also
proposed radical changes on B, which I think are probably orthogonal. Also
they are mostly editorial, though they might reduce the overall functionality of
BTP.
Quick
summary of what is in the current spec. (note that the proposed solution for 78
does not change this)
The
abstract messages include target address and (often) reply-address as ways of
stating, in abstract, where the message is going, and where a reply, where there
is one, should go to. There is no assumption that the carrier has any
request/response or reply-to mechanism at all, since the carrier is undefined at
abstract level.
The
other address parameters are either (in 0.9.1 and earlier) disambiguating the
identifier (these are deleted in 0.9.1.1), or are announcements of the
address(es) to be used for future access to some new entity. These latter are
sets-of-addresses, allowing for migration, alternates etc.
For
the xml, as a concrete encoding, most of the target address has been used to
work out how and where to send the concrete message. The "additional
information" is still there, allowing routing information that is not understood
by sender, and cannot be placed in any carrier protocol field to be sent to a
btp-understanding entity, which can then the message on where it will be
processed. The other address parameters are unchanged, although the
reply-address is always optional. The xml is designed to be
suitable for non-RR and RR carriers.
Once
we come to the bindings, the "request/response exploitation rules" define how
things work with a request/response carrier. These were added as part of
the solution of Issue 7, agreed at last conference call, and the effect is
summarised in the agreed solution of 7. For an implementation that wants to map
a BTP request/response directly to the HTTP request/response, it just omits the
reply-address as a real field in the outbound request. The receiver, by the
exploitation rules, is then forced to put the reply on the
response.
But if
an implemetation wants to, it can more or less ignore the request/response
nature and just treat HTTP as a series of one-way messages. In this case it does
put its own address in as reply-address on outbound BTP messages - and this
message may even arrive an http response and the reply be sent on a request, if
the other side is playing the same game. (The other side can decline the game by
sending the reply back on the carrier-response anyway)
---
So the
target-address and reply-address wouldn't be necessary if we had a hard mapping
to a request/response carrier (rather than the flexible one the "exploitation
rules" provide) . An interoperable implementation could be built that
never made use of them, other than to put other peoples (received) target
additional-information in outbound messages. It can ignore all incoming
reply-addressess (always using the carrier response), and never set its own
(only sending btp "request"s on http requests)
But
thought that's fine for a strict web-services environment, dropping the target
and reply addresses at abstract and xml level would lock BTP into
request/response worlds, which is hasn't been our intent as a committee (and
which would be most vigorously opposed by Choreology - on the basis of known
user requirements, not unbridled architectural ambition :-)
Peter |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC