Re: Updated architecture

Ok,

Let me try sending this again since I first had
to unsubscribe my old domain name.. and re-subscribe
my new one (even though they still lead to the same place :-D)

....

Randall Stewart wrote:
> Hi all:
> 
> I just submitted draft-11 of the architecture.. the main
> changes are the addtions of this in the intro section:
> 999999999999999999999999999999999999999999999999999999999999999999
> 1.1.  The Problem Space
> 
>    Fault tolerance is a difficult and challenging problem space.  Most
>    of the solutions in this space involve an extensive effort on the
>    part of an application programmer and oftentimes the result is a
>    proprietary solution.  There are a number of issues concerning
>    developers of fault tolerant applications including:
> 
>    1.  How to find a server that provides the service desired?
> 
>    2.  If the server that is providing me the service dies, how do I
>        find another one?
> 
>    3.  What type of redundancy model will I use, 2N or N+K?
> 
>    4.  How does a server providing a service share state with potential
>        peer servers in case of a failure?
> 
>    5.  How does a server assure that when it fails (or dies), the
>        clients will access the "best" server that is able to handle the
>        failure (or if you will take over for the departed server)?
> 
>    6.  From an operations and maintenance standpoint how do we add or
>        subtract capacity dynamically without reconfiguring our network?
> 
>    A fault tolerant application needs to deal with these issues and many
>    more.  Often an application is developed and then later, it is
>    realized that the application needs to be fault tolerant.  The
>    response to this new requirement mandates either a hack or re-write
>    of the application.
> 
>    So how can application writers solves these issues and makes it easy
>    for the application designer to add fault tolerance without hacking
>    or rewriting the application code?  We use layering to solve this
>    problem.  A session layer is inserted below the application layer to
>    provide a framework for fault tolerance.  This removes some of the
>    complexity from the application writers hands thus freeing the
>    application writter to concentrate on the application.  Note that not
>    all of the issues listed above can be solved by the session layer
>    framework alone, in particular the application will still need to
>    deal with state sharing, however the session layer framework will
>    also provide small tools when it can to help make even this job
>    easier for the application writer.
> 
>    A second important point is that this layering no longer requires
>    each application to custom programmed for fault tolerance.  By
> 
> 
> 
> Tuexen, et al.         Expires September 30, 2006               [Page 3]
> 
> Internet-Draft            RSerPool Architecture               March 2006
> 
> 
>    running an application on top of the session layer fault tolerant
>    services, there is no longer the need to design and implement fault
>    tolerance one application at a time.  There are several benefits to
>    this approach:
> 
>    1.  Time and cost savings for the developers of the application
> 
>    2.  Experts in the area have developed the session layer fault
>        tolerance mechanism
> 
>    3.  An application can be developed without a fault tolerant
>        requirement and later in the life cycle, if this requirement
>        emerges, it can be met with Rserpool without a costly redesign.
> 
>    4.  Rserpool provides a set of APIs and hooks for the application
>        developer to implement fault tolerance
> 
>    5.  Rserpool provides a simple building block to the application for
>        rudimentary state sharing.
> 
>    The above summary is the overall goal of Rserpool.  We strive to
>    remove the details and complexity of fault tolerance from the
>    application writer and, when the session layer cannot solve the issue
>    (such as state sharing), give the application writer some small
>    building blocks on which they can solve the problem with minimal
>    effort.
> 
>    In this document you will be introduced to a set of concepts for
>    solving a number of these problems.  Often times the document will
>    refer to a named element (e.g Pool User) in the architecture sending
>    or receiving a message.  When seeing this, please note that this is
>    NOT the application sending or receiving the query, but the session
>    layer below.  Envision if you will the application opening up a
>    special form of socket.  This socket will allow reading and writing
>    of data, but underneath will have special properties that allow it to
>    send and receive additional messages when the upper layer user
>    requests some service such as sending a message or binding a name.
>    Note again, the goal of RSERPOOL is NOT to solve all of the problems,
>    but to instead solve a subset of the fault tolerant issues and at the
>    same time provide a toolkit of standard utilities that will help an
>    application solve the remaining items in an easier way.
> 
> 1.2.  Overview
> 9999999999999999999999999999999999999999999999999999999999999999999999
> 
> 
> This, as discussed at the wg meeting, gives a better understanding (I
> think) to the reader as to what we are up to.
> 
> I also fixed a few typos and such.. but most of the rest of
> the document stayed the same... I did take out
> one extraneous paragraph.. that did not belong... but all in
> all the above is the main changes..
> 
> Comments would be welcome before I send this off to Fred...
> 
> R


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)