[Vrs-development] Domain Info and a "Historical Document"

[Chris Smith]

Okay.  This is just random stuff chucked to the list to give you something to 
chew over.

I think it's time we set the scene and put you in the picture with regards to 
the middleware messageing and domain stuff we have at our disposal.

This is a working document, and was inspired by your request for tech specs, 
so I'd really appriciate your input in order to turn this into a 'everything 
you need to know about goldwater before you get started' document.

http://www.nfluid.com/newdom.html

More will come - particularly with comment from you guys.

Also there is a really old and now rather out of date document that shows the 
'LDS with Goldwater' component model well. (You'll see from the description 
etc that I saw very little differnce in the sandbox nature of SEE and VRS).

JUST CONSIDER THE DIAGRAM ON PAGE 3 - the text is REALLY out of date!!!!!
In particular DO NOT read the stuff about DNS on page 4, I don't want to 
distract you from what Goldwater does for you - the DNS stuff will not 
support the type of cluster we're after anyway.... I told you it was an old 
document!!! (Mind you, reading it you can see how things have progressed).

http://www.nfluid.com/docs/gw-dotGNU-SEE.pdf

Some notes on the diagram:

- The services listed (like Cluster Manager services) are GWServices.
- The Network Server is something like Apache or Jabber etc providing a 
public Point Of Presence for clients external to the LDS/VRS.
- The external Web Service Requests bit was supposed to provide a network 
path for C# webservices to access external resources.
- The VRS network portal is the Goldwater Domain Bridge PLUS some VRS logic, 
which is why it's called 'VRS network portal' and doesn't mention Domains, 
being more than that in concept. "keep it simple stupid" basically... :o)


There is much that is totally rubbish in the document (like the DNS bit)!

Appendix A part 2 is interesting...... :o)

Actually, it's not too bad.  The description of the various bits is quite 
good, if a little miss-directed.

The important bit is that each major component is broken down into modules, 
each implemented as a GWService.  All the GWServices that make up the LDS are 
tied together using Goldwaters Message Queues (or publish-and-subscribe 
messaging - basically like raising and traping events, but the events are 
messages themselves).  The LDS-LDS comms are handled by the Domain Bridge but 
just looks like a regular Message Queue as far as the GWServices are 
concerned.


Anyway, thought it might provoke some talk!

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