[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] BTP Issue 29 : Redirection
Redirection
summary of previous discussion
The issue said we shouldn't include transport functionality in BTP. I sent a
message ( http://lists.oasis-open.org/archives/bt-spec/200111/msg00080.html
) saying that it wasn't general, but the particular need of the recoverable
Superior:Inferior relationship that meant it was needed. Mark Little
responded ( http://lists.oasis-open.org/archives/bt-spec/200111/msg00090.html )
- his message may appear to be a disagreement, but my text was intended as a
reductio ad absurdem, so we did agree.
Summarising that:
Implementations need to have the ability to restore or migrate Superiors
and Inferiors (of all varieties) to different addresses.
Since
then:
As was
mentioned at Liberty Corner (by Mark Potts, IIRC) there are proposals in the
SOAP world for mechanisms that would be more general and roughly of the same
functionality. However, that doesn't affect the requirment for redirection
in BTP at the abstract level. If BTP is bound to a carrier protocol that
provides full redirection capability, the REDIRECT message can map just to that
mechanism, and not have any separate existence "on the wire" (the binding
proforma allows for such implicit representation). But if the carrier doesn't
provide, we need to - which is the case with the current binding to current SOAP
1.1.
The issue 79 message split/renaming raised the question
of what happened with REDIRECT between Terminator and Decider. Since this is a
non-recoverable relationship, there is less need - and especially no need for
the pre-emptive use of REDIRECT (like a change-of-address card) - the Decider
doesn't retain the Terminators address (it appears only as reply-address on the
T->D messages) so wouldn't know where to send it. However, it would be
possible for a Decider to move (if the Coordinator moves, then its appearance as
both Superior and Decider would move). This suggests that we need a
FAULT(redirect) response (rather similar to CORBAs location-forward). Making
this a possible reply to any of the messages that get a reply (i.e. all the
Terminator -> Decider messages, REQUEST-STATUS, ENROL, BEGIN (bit
odd that one) would seem harmless. As with REDIRECT itself, it would map to
carrier constructs that did the same thing if there were
any)
Peter |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC