[Vrs-development] CM Manager Arrangement (was: Service Manager free-style)

[Chris Smith]

On Tuesday 16 April 2002 03:41, Open Source wrote:
> 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.

Glad you're back.

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

I'll answer this in two parts.
There is some confusion (now) whether or not each LDS in
the VRS cluster will offer ALL of the services available
in the VRS as a whole.
I'm of the opinion at the moment that LDS's will only
offer those services that it *wants* to offer, split into
types such as: (not comprehensive!)
a) CPU
b) Filestore
c) MY services

Combinations of these types would be used, such as
MY Services AND Filestore - which means that the LDS will
store and execute it's own services, and will also store
but not execute other services.
Or something along those lines.

Thus it *will* be necessary for LDS's to be able to route
requests to other LDS's for processing.

As for the routing itself, this is quite easy.
the LDS needs to know where a particular service may be
executed, and where it can be found.  This is part of
the LDS application, and thus still up for design.

The VRS is a cluster of LDS's.  Each LDS is built on top
of a middleware that will natively 'cluster' with other
intances of the application (ie other LDS's).

The middleware uses message passing to communicate between
the application components.  The messages are namespaced,
so 'clustered' middleware applications look like a single
application with the components of each 'node' uniquely
identified by namespace.

Message passing between components may be wildcarded, so
broadcasting messages to multiple nodes simultaneously
is a sinch.


The 'network presence' of an LDS is achieved by whatever
standard internet servers the owner of the LDS wants to
use.. Webserver, mail server, ftp server, whatever.
They just need to be configured to invoke the LDS handler
when a suitable request is received.


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

I meant that I'd rather a client didn't call an LDS
to access the VRS if that LDS couldn't satisfy the
request without redirecting/forwarding to another LDS.
This isn't going to be possible in most cases, so
routing will be important.

> I think the repository manager will resemble something
> like the Andrew file system but within a sandbox.

I need to have a look at the Andrew file system again.

Right now I'm concentrating on re-activating Domain
in Goldwater.....


Hope that clarifiesd things for everyone.
There are flaws in it I'm sure, but hey, we're all
helping to sort them out!


I'm going to need some coding help too in a few weeks,
who's up for it?


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