Re: [Vrs-development] Service Manager free-style

[Chris Smith]

On Sunday 14 April 2002 01:15, Eric Altendorf wrote:

> OK, I'm going to ask a dumb question here -- will these services be
> available on their standard respective ports (in which case the services
> manager sounds a lot like xinetd...?), or will it offer connections via a
> special services manager port, with its own protocol, unwrapping each
> request and dispatching it to the appropriate server?

The LDS as standard will have no network support at all (other than the
Cluster Manager - but that's internal so we'll ignore it for now).
It also deals with SOAP requests, which are transport independant.
So to get SOAP requests into an LDS you need to hook-up some servers.
If you want SOAP over HTTP, then install Apache and configure it into the
LDS.  If you want SOAP over SMTP, then configure sendmail into the LDS.
If you want Jabber, then blaa blaa blaa.

If these 'servers' are booted from /etc/init.d then so be it.  If you want
to have them started by xinitd, then that's up to you - though that's going 
to be terrible performance wise.

> And regarding the services/protocols supported -- do we intend on using
> stand-alone independent server processes (e.g., a standard Apache process)?

Suppose I've just answered that.
Bare in mind that because the LDS does not mandate what servers provide its
network connectivity, you can use whatever you want.  Even servers that 
haven't been designed and implemented yet.........

> I'd argue that we not require each LDS
> node to support the entire set of services.  If someone has a computer they
> want to donate to an LDS cluster, but they for one reason or another can't
> or don't want to run an EJB server, they shouldn't be prevented from
> joining and offering the other services.  Or maybe a node has lots of disk
> space but no spare CPU cycles, and it could be donated for storage but no
> services. Besides, nodes may experience temporary failures of certain
> services (e.g., Apache gets misconfigured and won't run) and that shouldn't
> interfere with the node's operation in providing other services.

Good point.  We've touched on this with the LDS level (I/II/III) stuff but
not as specifically tuned.  The VRS would be a MUCH better product if we did 
build this configuration in.

> Probably connections to an LDS node which does not support (at that moment)
> the requested protocol should simply be redirected to a node that does.

I'd like this to be achieved at the Service Discovery phase but, alas, the 
service discovery server views the whole VRS as a single entity and so may 
return *any* publicly facing LDS as a possible access point.  So routing will 
be important.  

It's far more efficient to have the request routed to the LDS that can 
satisfy the request and the result routed back, than have the accessed node 
get hold of the resource from the reomte LDS and run it locally, because the 
size of the resource may be far greater than request and reply put together.
Redirection is not possible as that functionality is not supported nicely by 
SOAP and similar protocols... it *may* work with SOAP over HTTP, because you 
can get HTTP requests to redirect - but I've never tried this with SOAP so 
can't guarantee it will work - it's certainly not in the spec.  It definately 
WILL NOT work with SOAP over SMTP, or FTP - so it's probably a no no.
Besides, the LDS that provides the requested resource may not be accessable 
publically, so redirection won't be possible.

> This suggests to me a layering separatation.  The VRS (as I see it)
> accomplishes two interesting things -- providing distributed and secure
> file storage, and providing services (through multiple LDSnode-to-Internet
> connections) which operate based upon the contents of the files.

V Nice summary.  Correct too! :o)


> Incidentally, the former sounds temptingly like the Andrew File System...?
> Anyone else familiar with that?  I wonder if there's any work there we
> could use...

OH MY! What a Blast from the Past!

> I guess the other thing the service manager should do is manage the list of
> other LDS nodes currently available.  That includes talking to other
> currently-available nodes to authenticate new nodes when those nodes come
> alive and attempt to join the cluster...no?

Yes-ish.  This node management is done by the "Cluster Manager".
I'm working on this a the moment.

Bill - Network support has arrived !  SIMPLE Domains are coming this week I 
hope.  Keep you posted.

> How far off base am I here? :-)

I'm about to pitch in your direction..... :o)

-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk