Re: [Vrs-development] CMM Messages

[Chris Smith]

On Tuesday 05 March 2002 16:19, you wrote:

> 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 will be in control of the load balancing.
GWDomains perform load balancing if a call is made
to a GWService  WITHOUT implicitly declaring a namespace.
As the LDS will be sending messages to specific LDSs
then GWLoadBal will not be performed.

> This sounds good.
>
> How is this state data synched bewteen different
> running instances of GW?

Piggybacked onto GWService requests across the network
and through polling.

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

But you've missed something :o)
What about scalability on a SINGLE machine.

Imagine you have four GWServers offering services
A, B C and D.

A is a GWService that accepts a webservice Request.
B Decodes this request and extracts all the info.
C Looks at the Repository for the service required
D Is actually the C# runtime engine

When A is called by a client, it invokes B which
invokes C which invoked D.
Whilst this is happening, no other client can
have requests serviced because A is busy.

If a remote LDS calls out LDS and wants to get
resource data it calls Service B.  But it can't
because it is busy in the chain from A->D.

So to 'scale this up' you boot multiple instances
of A, B, C and D.

Small machines which have limited resources might only
boot three of for instances of each server.

Beefy machines with lots of memory and CPU cycles may
boot LOTS more.

Plus you can TUNE the application by booting more of C
than say the others, so requests for data from the
repository can be done in parallel.

Also, should one of these services be temporarily
busy, Goldwater will efficiently queue the messgae
in a FIFO, so the caller need not know that the service
it is requesting is busy at all (unless the request
times out because it queued too long).

THIS is the scalability I was talking about.  Scaling
over multiple machines is an extension of this by
making the message routing/queueing transparently
span a network instead of just being local machine
IPC - the application doesn't see or know any different.



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

Time is the problem really.
I've got to rewrite GWDomains to facilitate namespacing
and the features that LDS wants to build on!


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

You're thinking about converting perl modules to C
and having them distributed across the cluster on each
LDS, and have a single LDS call these 'modules' on
remote LDSs to access the data held there.
You are aren't you?


GWServices can be anything that takes a request and
returns a response.  In fact, they don't even have to
return responses.  And they don't have to do anything
with the request if they don't want to.


Its very difficult to assess what you're planning to
code wrt Goldwater implementation.

I'll *try* and put together a scenario of Goldwater
usage - I'll  base it on the system I'm developing
at the moment (not using Goldwater though :o(  - but
the architecure is *exaclty* as GW would implement
it).

This might tie up the loose ends in both our
thinking.


Chris


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