Re: [Vrs-development] CMM Messages

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> On Monday 04 March 2002 20:48, Bill Lance wrote:
> 
> It's a runtime configuration parameter.  It is not
> dynamic though, so you have to stop the LDS, change
> the value and restart.
> 

Humm ...  well, several thoughts.  Does this number
have to be the same for all running GW instances?  If
so, we will have to preset it at a  high level.  If it
can be different in each LDS instance, we perhaps can
find a way of twicking a runtime configuration
parameter.  We are certainly going to need a
configuration file for the LDS anyhow.



> > 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.
>

These load balancing stats are something I've had in
mind as part of the CI.  Perhaps they will already be
available in GW.  They are needed to decide which LDS
to forward a net-service request on to.  I see this as
a two part decision.
  
1) If any node currently has a requested service
chached from a recent similar request, then that node
gets the job, unless it's currently busy.  .  

2) Pick a target by evaluating availability and load
stats.
 

> 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.
>

This sounds good.  

How is this state data synched bewteen different
running instances of GW?
 
> 
> 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, 

Totaly agree here.  


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 think I understand what you are saying about GW and
scalability.  It's the same mindset as OO programing
in many ways.  Also, I can definately see the value of
GW as an internal framework for an application that
may need to quickly scale from one to N number of
machines, say because of rapid growth of demand.

But in this case, at the Server Layer, the LDS as a
single implementation on one host machine is not going
to change.  Load growth is handeled by adding nodes
withing the VRS framework, not by scaling up an
individual LDS node.

And I talking about just within the Server Layer
itself, intermodular communication within the same
LDS.


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

You mean the GPL release?

Hum ...  ya  ..  hehe

could you cobbel together a gnutilla client?

That should add some excitement to recent events is
the fileswapping world.   :)
 

 
> 
> 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.
> 


How does this work when used in conjunction with PERL?
 I don't see how to approach the prototyping phase if
I understand you correctly.

My original thought was to convert perl logic to C
modules, but the remaining perl still glues the C
routines together.  Your approach sounds like that
gets turned upside down.


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/