RE: [bt-spec] BTP Issue 29 : Redirection

[Peter Furniss <peter.furniss@choreology.com>]

There was no comment on my message a month ago on this, so I'm going to propose a solution on that basis.

 

This solution is a bit more compliated than some of the others have been. I have put in a rationale, as part of the solution. This can be the basis for text in to go in the model/explanation part (the rationale here has deliberately been made concise)

 

The main part of the rationale is about the REDIRECT message and the Supeiror:Inferior relationship - this makes only editorial changes to the normative part.

 

The FAULT/redirect does make technical changes

 

 

Proposed solution

 

Rationale

 

Redirection is needed in BTP, at the abstract level, to support implementation approaches where a recovered actor playing Superior or Inferior roles has a different address to its original one. If a particular carrier protocol has support for redirection in a way that is sufficient, then a BTP binding to that carrier can map REDIRECT to that mechanism, and the REDIRECT message itself (as an XML or other encoding) would not appear in exchanges using that binding.

 

The description of "implicit messages" in the carrier protocol binding omits mentioning that a message may be implicit because it is mapped to carrier construct (although this is in fact what happens that section in the SOAP binding specifcation).

 

SOAP 1.1 does not have such a mechanism, and for the present bindings the REDIRECT message is used for the Superior:Inferior relationship.

 

The abstract message text in 0.9.2 is aligned with this, but the Redirector role description is not.

 

On the non-persistent relationships, communication is always initiated by one actor (in role of Initiator, Enroller, Terminator, Status requestor, Redirector) which has the address of the other (Factory, Superior, Decider, etc.), but the target of the first message will use the reply-address (or reply mechanisms of the carrier) for the reply and does not know the other's address a priori. (The messages are all effectively request/response). The REDIRECT message is therefore not used on these relationships.

 

However, since the actors on the non-peristent relationships can also move (often because they are also Supeiorr or Infieorr), a new FAULT/redirect can be used as a response to any of the request/response messages, carrying a list of one or more replacement addresses.

 

Changes

 

 

In the Redirector role desription, change the first paragraph to:

 

Sends a REDIRECT message to inform a Superior or Inferior that an address previously supplied for the peer (i.e. an Inferior or Superior, respectively)  is no longer appropriate, and to supply a new address or set of addresses to replace the old one.

 

Change the parenthesis at the end off the paragraph that begins "If a Superior moves .."

 

(Note that the inbound message may itself be a REDIRECT message, in which case the Redirector shall use the new address in the received message as the target for the REDIRECT that it sends.)

 

Delete the paragraph "A Redirector may also be used to change the address of other BTP actors"

 

In the carrier protocol binding proforma, paragraph "Implicit messages", add "carrier-protocol mechanisms," before the first "application messages".

 

In the list of faults, add a row

 

fault-type = Redirect

 

Meaning = The target of the BTP message now has a different address

 

fault-data = Set of BTP addresses, to be used instead of the address the BTP message was received on

 

In the fault list for REQUEST_STATUS and REQUEST_INFERIOR_STATUSES add

      Redirect – if the intended target  now has a different address

 

In the fault list for ENROL add

    Redirect – if the Superior now has a different address-as-superior

 

In the fault list for BEGIN add

    Redirect – if the Factory  now has a different address

 

In the fault list for PREPARE_INFERIORS,CONFIRM_TRANSACTION,CANCEL_TRANSACTION,CANCEL_INFERIORS add

         Redirect – if the Decider  now has a different address-as-decider

 

Align the XML with the additions for FAULT.

 

 

 

 

Peter

 

 

 

 

 From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 25 January 2002 11:49
To: bt-spec@lists.oasis-open.org
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