[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] Re: [DotGNU]Network SEE architecture, v2
From: |
Chris Smith |
Subject: |
[Vrs-development] Re: [DotGNU]Network SEE architecture, v2 |
Date: |
Tue, 8 Oct 2002 11:14:07 +0100 |
> http://csserver.evansville.edu/~sc87/see-arch.txt
I read this with interest.
This post is an off-the-top-of-my-head comparison of the SEE and the VRS.
I can't get it out of my head that the SEE and VRS are very similar beasts:
SEE VRS
Accepts requests for Y Y
webservices from 'users'
Accepts request for Y Y
webservices from other
nodes
Runs Webservices Y Y
Provides a secure exec Y Y
environment
Distributes resources N Y
uniformly across the
cluster
Supports multiple Y Y
protocols/transports
Supports the addition of Y Y
new protocols/transports
Requires identification Y Y
... There are more pluses for the SEE and minuses for the VRS and vice-versa
I'm sure, but this is just off the top of my head :o)
Basically, a single node in a VRS looks like a SEE. How executables/data is
stored is very much 'local' in the true SEE sense, and distributed in the VRS
sense. How/where data is stored is handled by the Resource Manager of the
VRS and will be entirely local if the VRS contains a single node.
I see no reason why an 'equivelent' Resource Manager could not be substituted
for the VRS default to provide the entirely local storage and
forward-to-another-SEE-node behaviour required by the true SEE.
How someone adds 'echo servers' to the VRS and requests access to webservices
stored in the VRS has not been identified.
>From what I've read in your SEE document it looks like you've identified all
the important bits. In terms of protocol/transport the VRS is modular with a
well defined internal messaging API. Adding a Jabber transport mechanism is
as straightforward as writing something that listens for and understands
Jabber messages and can inject them into the VRS in the internal format. Easy.
You also need an equivalent that takes the resultant message coming out of
the VRS and fires it back as Jabber.
The equivalent in the SEE are seeport and seeuser.
I think we should all team up as there is already architecure in place for
the VRS that provides all the stuff the SEE is looking to require.
However, the architecure used by the VRS has not been ported to M$ as it uses
SysV IPC (message queues and the like) and shared memory. Something needs to
be done about that, any volunteers???? :o)
Okay you peer types.... comments?
Chris
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk
- [Vrs-development] Re: [DotGNU]Network SEE architecture, v2,
Chris Smith <=