[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] Service Manager free-style
From: |
Chris Smith |
Subject: |
Re: [Vrs-development] Service Manager free-style |
Date: |
Mon, 15 Apr 2002 11:54:07 +0100 |
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
- Re: [Vrs-development] Jabber and VRS, (continued)
- Re: [Vrs-development] Jabber and VRS, Chris Smith, 2002/04/11
- [Vrs-development] Ready to help, Eric Altendorf, 2002/04/11
- Re: [Vrs-development] Ready to help, Bill Lance, 2002/04/11
- Re: [Vrs-development] Ready to help, Eric Altendorf, 2002/04/11
- Re: [Vrs-development] Ready to help, Bill Lance, 2002/04/11
- Re: [Vrs-development] Ready to help, Chris Smith, 2002/04/12
- Re: [Vrs-development] Ready to help, Bill Lance, 2002/04/12
- [Vrs-development] Task list and project activity, Bill Lance, 2002/04/12
- [Vrs-development] Service Manager free-style, Eric Altendorf, 2002/04/13
- Re: [Vrs-development] Service Manager free-style, Bill Lance, 2002/04/14
- Re: [Vrs-development] Service Manager free-style,
Chris Smith <=
- Re: [Vrs-development] Service Manager free-style, Bill Lance, 2002/04/15
- Re: [Vrs-development] Service Manager free-style, Eric Altendorf, 2002/04/24
- Re: [Vrs-development] Service Manager free-style, Open Source, 2002/04/15
- [Vrs-development] CM Manager Arrangement (was: Service Manager free-style), Chris Smith, 2002/04/16
- Re: [Vrs-development] CM Manager Arrangement (was: Service Manager free-style), Bill Lance, 2002/04/16
- Re: [Vrs-development] Service Manager free-style, Eric Altendorf, 2002/04/24
Re: [Vrs-development] Jabber and VRS, Bill Lance, 2002/04/11