Re: [Vrs-development] new to vrs

[Chris Smith]

On Thursday 04 July 2002 17:31, Ian Fung wrote:
> hello, just wanted to post and say that i'm interested in work on vrs. i
> have been looking at the dotgnu page lately and am really interested on
> vrs. my resume is here so you can get an idea of what i can do.

Excellent.  The more the merrier.
Everyone has been extremely busy with other projects (money!) of late, so 
there's not been much visible activity here for a little while.

I've been doing lots of background middleware stuff, and trying to get an XML 
Gateway out of the door for a client of mine - busy busy busy... but I should 
be back properly soon.


> http://www.people.cornell.edu/pages/if26/resume.htm

Cool.  (Just a note - foreground colour is defaulting to black so you get 
black text on a black background with quite a few browsers.... quite an easy 
thing to miss - I do it all the time!)

> please let me know how i can start contributing.

We've established that the VRS will be middleware based.  The middleware will 
handle all the inter-node/cross network message routing (effectively hiding 
the fact that there is a network there at all), so we need to build the VRS 
as a set of inter-calling functions deployed aross the middleware.

Are you familiar with application development using a middleware?

The VRS is split into three parts.  A Cluster management system which handles 
which nodes are connected to which other nodes - and this relies quite 
heavily on management informaion passed back from the middleware which is 
physically handling the connections.
The second part is the Resource Manager.  This handles how resources are 
distributed across the cluster.  It's kind of a RAID based distributed 
filesystem.
Thirdly is the network server and portableNet handling.
The network server part receives SOAP/XML-RPC/Jabber whatever, it's just a 
set of access points which receives a requests and routes them to the 
middleware.
The portableNet stuff gets passed the required code retrieved from the 
Resource Managers data pool which exists over the Cluster managed by the 
middleware.

This third bit is the easiest, and may be made to work in the absence of the 
other two - effectively providing a single machine application that can 
service requests for C# et-al services.  You just stub the RM to get 
resources straight of disc - i.e. define and implement the RM API and cheat 
with the internal implementation.

So there's work to do in all areas.

What interests you?

I'm probably going to be leading the Cluster Manager side of the project, 
because of it's tie-in with the middleware.

Bill Lance (who's currently away ill - and we hope getting better :o) ) was 
going to lead the Resource Manager part, as he designed the VRS in the first 
place and gets quite excited at the RM concepts.

It is clear that most of the development work will be in design, then frantic 
'black box' development/implementation.  It's no the sort of project that can 
be designed at the keyboard - besides, there are a lot of parallel tasks, so 
work should progress quite quickly once we all get started.
No decision on implementation language has been made yet.
I'll stand up and fight anyone with C/C++/Perl etc, but I must confess to 
being a Java/C# pussy  (I've a C# book now though!).  Time and work pressures 
really dictate my limited venture into these areas.

Not using an unprotected language such as C/C++ is a 'Good Thing(tm)' as far 
as team development is concerned.  However, we should really capitalise on 
the strongest and most common set of skills available.  I note that you're 
quite a Java programmer.  Good.
If we go down the Java route, I'll catch up I'm sure.  Mind you, being 
middleware based, it doesn't matter what language you develop an application 
fragment in, as the API remains consistent.

I'm concious that if I don't get the middleware stuff up to speed in terms of 
Domain handling, then start up will be slow.  I'm working on it, but <sigh> 
lots on at the moment.

Hwoever, work on the RM side of things can definately start now - as the 
lower layer of the 'protocol' (ie *where* data may be found) is the only 
thing that needs to know about the middleware... so design can proceed above 
that if some sensible assumptions are made.. And of course I'm here if anyone 
has any questions.
Hmm, the webservice/portableNet stuff could also be started, as the the 
Middleware is just missing the domain support.  You're restricted to C/C++ or 
Perl though.  A Java API is coming, as there's a nice chap on this list 
looking at that - but he's busy too!

Have a look at http://www.nfluid.com - the Goldwater Middleware section has a 
load of info about the middleware.

Cheers,
Chris

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