|
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.
I'm not sure we gain much be splitting, but we can give
it a go!
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.
Since we are always expecting to do mapping of BTP to
specific carriers, I would argue that the information specific to delivery (RR
or not) should go into a carrier-specific section. If I want to understand the
BTP protocol I shouldn't be expected to have to wade through the information
about how a particular message gets from A to B. It'd be like telling someone
that in order to understand the two-phase commit protocol in the OTS they had to
understand how the ORB sends and receives messages.
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)
I'm beginning to think that some (much) of the
confusion we're having is that some you think of BTP as encompassing all levels
from the socket up to the actual transaction engine, whereas what we've been
thinking of as BTP is two separate things: the delivery and the functional
message. The latter doesn't change from one carrier-binding to another, the
former does. If we work on the basis of this separation then request/response
(or not) falls into the carrier aspect of the protocol. It's the carrier-binding
part of the BTP message set that may change from SOAP-to-email-to-carrier
pidgeon-to-... not the functional part: the message the carrier pidgeon takes
that says "commit transaction X" is the same as the one that the SOAP transport
takes, it's just that the pidgeon flies through the air avoiding houses and bad
weather (and probably goes faster than SOAP!)
---
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)
So we load up the functional part of a BTP message with
carrier information?
But
thought that's fine for a strict web-services environment,
Good, because after all we are working in a
web-services world here.
dropping the target and reply addresses at abstract
and xml level would lock BTP into request/response worlds,
Hopefully the above
helps.
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
:-)
And likewise our arguments are based on known
requirements.
Mark.
----------------------------------------------
Dr.
Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna
Labs
Email: mark_little@hp.com
Phone: +44 191
2606216
Fax : +44 191 2606250
|