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

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

Redirection is not in BTP as a general purpose capability, but because it is needed to make BTP, as a recoverable transaction protocol, work within the loose, heterogeneous environment we are targetting. It's the recoverable nature of BTP that makes it essential - the superior:inferior relationship is expected to survive failure, and, since we are talking about long-running transactions (for some sense of "long") also needs to survive deliberate shutdown. It isn't a matter of including transport functionality, but of making BTP work. (if some already existing transport mechanism had this functionality, we might be able to use that instead, but there isn't one, so we have to roll our own)

 

For some implementation strategies, a recovered/restored BTP actor will always come back at the same place, for all time. But for others, it seems the address might be different - either on a relatively short timescale ( process lifetime, system restart) or relatively long (but still shorter than the lifetime of "long-running" transactions.) - system upgrade for example.   And remember the "address" is not just the binding address (a URL for SOAP bindings) but includes the additional-information, which might definitely be process-specific.

 

The existence of the REDIRECT capability (and the set of addresses) makes it possible for implementors to choose whether they use a fixed-for-all-time address or a more dynamic mechanism. (similar to the differences between LU 6.2 and OTS in this regard actually).

 

REDIRECT could only be removed from BTP if the following assertion is acceptable:

 

"All BTP implementations must ensure that any recovered BTP actor has exactly the same address when it is restored after failure as it had originally."

 

Splitting REDIRECT out seems problematic because it would suggest this was a general-purpose facility, and that would then mean we ought to consider other potential uses and requirements. Keeping it inside means it does what we need, and that's all. (Interesting to compare with the multiplexing sub-protocol in TIP - this was originally proposed as general purpose, but was confined to TIP only. To the best of my knowledge, it hasn't been taken up for anything else - whereas BEEP is general purpose, and does have multiplexing, and is being built on)

 

I would propose no technical change.

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

-----Original Message-----
From: BTP issues maintainer [mailto:peter.furniss@choreology.com]
Sent: 08 November 2001 13:28
To: bt-spec@lists.oasis-open.org
Subject: [bt-spec] BTP Issue 29 : Redirection

This issue has been added to the BTP issue list

BTP Issue 29 : Redirection

Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue H
Submitter's title: Participant timeout impact needs further discussion.
Note: The original title doesn't seem to correspond to the substance
Category: technical
Detail:
(Submitter documents are email from Alistair Green 20011023, BEA 20011018) Alistair Green's rebuttal, supporting including transport functionality into BTP, has a sound motivation, but complicates BTP while violating generally accepted layering approaches. At the least, this belongs in a separate specification (SOAP with redirection? Generic redirection protocol?). His argument that it is necessary doesn't mean it should be standardized via a back door such as BTP. There are many other things about which one could make the same argument. (e.g., reliable messaging, dealing with failed message routers)
Proposed Remedy:
Eliminate the redirector and related message from the specification. Submit this functionality to an appropriate standards group, e.g. W3C XML Protocols. In the alternative, break it out clearly as an enhancement to messaging services, and giving it a separate section to make separate use easier.

---

To comment on this issue, please follow-up to this announcement on the bt-spec@lists.oasis-open.org (replying to this message should automatically send your message to that list).

The current draft, with line numbers is available in pdf format and word format.

To add a new issue, please email to Peter Furniss peter.furniss@choreology.com. It helps if you propose a category (technical, minor technical, editorial, minor editorial).