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.
PRF:
The delivery-specific bit does go in a carrier-specific bit - that's
what the bindings do. We have various layers (loosely speaking), so you
can re-use the XML on various carriers, and we split out the RR
rules because they are likely to be useful to more than one
binding.
PRF: But thought the
abstract messages may not know how they are encoded or delivered, they do need
to have a way to say "this message is sent to where that one said it could
go". Editorially, it might be that the target and (perhaps) reply address
should be pulled out from the parameters of the abstract messages. But they
are still attributes of the abstract messages in some sense. And if the
encoding doesn't have a place for them, the bindings (or at least some)
would need extra wrappers to carry that information where it wasn't carried by
or implicit in the carrier. The same thing is done effectively with optional
fields.
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!)
PRF: Some of the BTP
messages are themselves request/response - all the Terminator/Decider
ones for a start. So, at abstract level, they need to say either that
they can ONLY be carried by RR protocols, or that the request includes an
(abstract) reply-address, (and, when we find it is an RR carrier, at
some point the reply-address can become implicit - current spec actually
leaves it to per-instance requestor's option, but it would be possible to
force the choice in the binding)
---
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?
PRF: from the
conversation with Jim, it would appear that, using your location-significant
URLs for identification, the message changes even more from one carrier
to the next. That works by burying the equivalent of the
additional-information somewhere in the URL (so the trick of using a nominated
URL won't work, it does have to be the one used to choose the pigeon - or you
have both urls, or the URL and the additional
information)
PRF: I would concede that a
strict separation would for some bindings put the additional-information and
the reply address on a wrapper just around the message (or
related-group), rather than as optional fields of the message, and for
other bindings that information would be handled by the carrier. But,
unless we reduce its current flexibility and functionality, soap-http-1
binding would use the wrapper, so I'm not sure what wouldn't - in which case
it may as well be in the message.
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.
Of course, though I
can't see what functional gain you think you're getting anywhere. Some risk of
functional loss. Style and presentation and even encoding don't affect
function
.
Peter