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

[Chris Smith]

Stuff I sent stephen a couple of days ago.

----------  Forwarded Message  ----------
Subject: Re: [DotGNU]Network SEE architecture, v2
Date: Wed, 9 Oct 2002 18:36:18 +0100
From: Chris Smith <address@hidden>
To: Stephen Compall <address@hidden>


... chop ...


Some stuff that springs to mind:

You make much of pipes and other IPC ideas in your documents which the VRS
also requires (IPC that is).  The reason I got involved in dotGNU (apart from
it being a damn important thing to be involved in) was that I had a language
independant middleware that could be used to tie all the process components
of a the VRS together.  In addition to this, it also provided the same IPC
mechanisms transparently across networks.  Suddenly a simple single machine
application could become distributed without writing any network code!  This
was very attractive from the VRS standpoint.

The bit when a SEE gets a request that IT can process is the same for the
VRS.  Even the logical layering (right down to the fact that you've described
them as processes [seedaemon, see*port etc]) is the same.  We're using GW to
tie these processes together.  I wonder if the SEE can't as well.

I notice that you suggest using Serveez.  I'm not familiar with that.  The
VRS is being built around a middleware that does all the single-machine
inter-process-comms for you and also inter-machine comms too.
However, we (the VRS) will still need some sort of network presence for the
request/reply transport.  How this will be done is undecided - possibly use
off-the-shelf daemons like Apache and Jabber for this.
What are your thoughts on this area for SEE?

So given that both our designs are so modular with a significant
functionality cross-over, I'm kind of hoping that we can factor out the
comminality (which is effectively the receive, decode, fetch, execute and
return bit) and provide a SEEinterface module and a VRSinterface module on
top.

... and wouldn't it be great if a VRS could behave as a SEE as far as other
SEE's are concerned... just enable the SEE layer and presto!

One think that I need to keep in mind is that Goldwater Middleware has not
been ported to Windows.  Not a mammoth task, but does need inter-process
shared memory.  Mind you its API is very clean and straightforward, a Windows
equivalent 'middleware' could be created that adhears to this API - sort of a
GoldwaterLITE, but without all the performance benifits and scalability
features.  That way the application code stays the same, the architecure
underneath changes instead. This might also be useful for un*x, for people
who want to run a simple not-particularly-tunable VRS-nay-SEE-nay-VRS
application.

Sorry, ranting now.  Probably too much information.  Got carried away.
There's also a lot of Goldwater info on my website.  I'd recomend (SKIMMING)
the white paper - just look at the picture (figure 1). And the incomplete
Tutorial (yet another picture to look at).  These pictures show the modular
nature of Goldwater that we're using to tie the VRS components together.  I
imagine they look pretty similar to your diagrams of the SEE :o)

Later.
Chris

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