Re: [Vrs-development] CMM Messages

[Chris Smith]

On Monday 04 March 2002 20:48, Bill Lance wrote:
> > The maximum number of LDSs our local LDS can
> > know about at any one time is n.
>
> How much of an over head is each n?  Can this be set,
> or reset at run time instead of being compiled in?

It's a runtime configuration parameter.  It is not
dynamic though, so you have to stop the LDS, change
the value and restart.

> What in detail is the GW set?  (Same question as
> above, I supose.)

IP address and Port number of each remote GWDomain (LDS).
(This could be a DNS name though instead of an IP)
The Services publically exported by each remote GWDomain.
The namespace associated with a remote GWDomain.
The availability status of remote GWDomains.
Load Balancing stats of each remote GWDomain.

The LDS would use the namespace of a remote LDS to be
able to route GWService calls to the CI or RM etc
layer of the remote LDS application.

If any of these calls fail, the LDS may feedback this
info to Goldwater who may then decide to mark the
remove GWDomain as unavailable.  Goldwater may
periodically ping the remote domain to see if it
responds and then change this unavailability status.

> My next task was to start detailing the CI data
> structure, so this is most timely.

> Does it make sense to use GW for communictions
> within this Server Layer?  All the modules, including
> GW, would be equally exposed to all other with API's
> within the LDS instance namespace.  Does GW add value
> in this case?

I'm not sure what your asking here :o(

With regards to using GW as the communication mechanism
between layers, then I'd say definately, and even go as
far as to say that it is essential that individual
components of a layer use Goldwater comms too for
scalability and abstraction.
GWDomain handling within GW is an *extra* optional
feature.  You don't need it or want it in every case.
GW allows you to build scalable client/server apps that
can run on a single machine or multiple.  To make an LDS
really scalable you should build it as a GW application
and not an application with Goldwater wrapped around
it later to give you some network features.
TBH, it's a funny mindset to get into.  Once you're
there it's obvious, and the way through is clear.

I need to build a 'demonstration' application to
release with Goldwater to help new developers on their
way.  Any suggestions?


Anyway, back to the question: If I get you to revisit :

http://www.nfluid.co.uk/goldwater/docs/gw-dotGNU-SEE.pdf

See page 3 for the diagram.
(ignore the SEE references!)

You'll see components of the LDS distributed as GWServers
around a GWRequest Queue.  Functional units which may
be used in parallel need to be within GWServers.  You
can have GW install multiple instances of any GWServer,
and thus have multiple instances of the functional
GWServices contained within them.  This is VREY important
for scalability.  You do not want to bung everything into
a handful of executables that run together.  You need a
finer grain of abstraction.  In the same way that you
don't implement programs as a single subroutine/function.
You modularise it, breaking it down into smaller
subroutines and functions, the collection of which
provides the application functionality you're after.
You do the same with GW, except that the functional
units are compiled into seperate GWServer executables
and not compiled together as a single executable.

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