[Vrs-development] Rough idea for a service manager

[Eric Altendorf]

This is a pretty sad plan, but it will give us something to talk 
about.

---

First, we need an API for services -- and I'm thinking a C# interface
along the lines of the Java Servlet interface.  I'd call them
VRSService's ("EOD"'s??), and any such services must simply conform to
(implement) this interface.  Such an interface must include: (a)
initialization methods, (b) service request-response methods, and (c)
metadata so that the cluster manager can determine which nodes offer
which kinds of services... (all that has yet to be formalized)

(As a side note: using a C# interface allows us to write VRSServices 
in
any IL-compilable language.  In the future, the C# VRSService 
execution
system should be replaced with SEE, for truly portable cross-language
functionality.)

The service manager listens on a port for administration requests.
Valid requests (at this point) are: install or uninstall a service,
and activate or deactivate an installed service.  Communication with 
the
SM administration process is done via a special SM administrator 
client.

To create a new service, you must first write a class which implements
the VRSService.  You then connect to the service manager on the
administration port, authenticate etc, request a service installation,
and send the compiled VRSService to the service manager.  The service
manager persists this service (via the resource manager) for later 
use.

Once the service is installed, you can request the service manager to
activate it, with particular initialization parameters.  The service
manager instantiates the class and initializes it with the provided
parameters.  It is now active, and incoming requests received by the
service manager are packaged up into the appropriate format to pass to
the processRequest() (or whatever) method of the VRSService.  The
results are then passed back to the client.

----

Eric