[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Service manager plan
From: |
Eric Altendorf |
Subject: |
[Vrs-development] Service manager plan |
Date: |
Mon, 7 Oct 2002 16:31:36 -0700 |
User-agent: |
KMail/1.4.1 |
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