[Vrs-development] Re: [DotGNU]Network SEE architecture, v2

[Chris Smith]

> 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