OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC