[Vrs-development] Service manager plan

[Eric Altendorf]

OK, cool.  Thanks for the feedback, Chris; I think we're going to 
start making progress here.  

With regards to the question to cache in RM or SM....  Honestly, I 
think both.  Of course the RM will need to provide caching.  However, 
high-performance web servers load the web services they provide into 
memory just once and keep them there, despite the fact that their 
underlying operating system and perhaps even the hardware itself 
provides caching.  Even if the RM caches, it seems excessive for the 
SM to have to load the EDO from the RM every time.  If the SM runs 
out of memory, sure, it can start unloading EDOs it hasn't used for a 
while...we could discuss that later in Version 2. :-)

Based on your ideas, here's my second try at a SM description:

----------------------------------------------------------------
ABSTRACT: Each LDS in the VRS will require a module to coordinate the 
reception of service requests and their actual fulfillment by the web 
services (aka EDO's).  This module is known as the Service Manager 
(SM).  This document describes the operation and requirements for the 
Service Manager.

1. General operation

The SM has two general interfaces: the service interface and the 
management interface.  The service interface receives requests (from 
inside or possibly outside the VRS cluster) to execute EDO's, using 
some standardized protocol (HTTP, Jabber, XML, etc).  The management 
interface will be a GWService that receives requests (only from 
inside the VRS) to change SM configuration options.

2. Configuration and the management interface

The VRS cluster is configured with a list of EDO's.  This list as well 
as the EDO's themselves are saved in the resource manager.  Each LDS 
can enable any subset of these EDO's.  Only EDO's which are enabled 
by a node will be executed on that node.  Additionally, for an EDO to 
execute, it must be loaded into memory from the RM.

The management interface of a given node must provide methods to 
enable and disable a specific EDO on that node.  The management 
interface should also provide methods to load, unload, and reload a 
specific EDO.

3. Service interface pseudocode

The service interface of each SM seems easiest to describe (IMHO) in 
pseudocode:

        wait for incoming EDO service request;

        if requested service is enabled 
                if requested service is not loaded
                        load it
                fi
                execute requested service and return result;
        else 
                look up node with requested service enabled
                if no such node
                        return error
                else if communication protocol supports a redirect
                        return redirect URL
                else
                        call requested service on remote node
                        package result and forward back to caller
                fi
        fi
        
        repeat.



-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi