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

[Open Source]

Sorry, to be out of the loop for such a long time. I
still catching up with old mails. Don't be surprised
if i bring up old stuff.

> > 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.
Let me get things clear.
For eg:
The web service uses SOAP over HTTP. It requests the
VRS with "Requesting information from this IP
address(the public IP) and the port is 80". The VRS
cluster identifes the SOAP request and redirects it to
the LDS handling HTTP requests. Internally, How do we
plan to handle this? ie. does a daemon receive the
request and redirect it to the port on which the LDS
service is listening? .....

> > 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. 

Reminds me of address@hidden

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.  

Can't this be achieved at the subscribing phase?
Something like, these are the set of protocols that
are supported. This will be help the VRS to discard
that LDS as part of the VRS cluster to handle the
current request. This will prevent the request from
getting routed and rerouted until the request is
handled by an LDS which understands the protocol. It
is something like getting repeatedly into a blind
alley knowing that it is a blind alley. :-)
 
> 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 think the repository manager will resemble something
like the Andrew file system but within a sandbox.

> > 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)

How many strikes so far? :-)


-Morphius


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/