Re: [Vrs-development] CMM Messages

[Chris Smith]

On Friday 01 March 2002 19:24, Bill Lance:

> This brings a question to mind.  How does GW get
> configured in the first place?  It faces the same
> configuration issues that the VRS does.  It starts
> with only one, other nodes are added, and the original
> one may drop off line.  A new instance of GW must
> start each time a LDS comes online and sync with the
> other GW components to other LDS's.  If GW
> configuration data is not carried in the CI, you will
> still have to accomplish similar mirroring tasks.

In this application, GW would be configured with n GWDomain
slots, but none filled.
Which GWDomains (ie remote LDSs) the local LDS knows about
is configured dynamically by the LDS itself because the
local LDS runs through the GWDomain API.  The maximum
number of LDSs our local LDS can know about at any one
time is n.

i.e. the LDS gets a 'Hey I want to Subscribe' message from 
another LDS, it checks it out and then tells Goldwater about
it.  Goldwater then deals with the whole up/down and 
routing thing.

Hmm (just had a look at the your documentation again....)
I think the cluster management is performed by Goldwater.
But all it knows about is how to manage the availability of
cluster machines and the routing of messages between them.
Any additional business-logic details about these machines
is left up to the application - the LDS in this case.

The subscription of an LDSs to a cluster is an function of 
LDSs and not Goldwater.  If the LDS tells Goldwater about
the remote machine, Goldwater can get on with managing its
availability and routing messages to it.  Goldwater is
there to support the application built apon it.

Yes both Goldwater and the LDS application will have
tables containing slightly overlapping data sets.
Its like having a normalised database where a single
chunky table is split into two tables, both keyed on
the same value(s).

Whatever is in Goldwaters table the LDS can 'see'
through the API.  Whatever is in the LDS table
Goldwater CANNOT see 'cos that is application sepecific.

We're effectively ripping out of the data stored in
the LDS CI whatever Goldwater needs to manage the CI
routing etc and giving it to Goldwater.  The LDS
application can still get at it and uses it to
augment the data GW doesn't care about.

I've probably repeated myself a little bit in that.
Sorry if I did.  Do you see what I'm getting at?  Take
the functionality that the CI needs to perform and
axe off those bits which Goldwater does for you.
Add in a bit of functionality to smooth over the
seperation and you'll end up with two cooperating
function sets that together form the CI.

> In the LDS block diagram in the Docs, would it make
> sense to place the GW component bwwteen the port
> manager and the others?  Like this?
>
> _______________________
> |      Port Mang      |
> -----------------------
> |          GW         |
> -----------------------
> | RM    |  CM    | SM |
> -----------------------

More like this I think:

________________________
|        Port Mang      |
+-----------------------+
|          GW           |
| ,----. ,----. ,----.  |
| | RM | | CM | | SM |  |
| '----' '----' '----'  |
|                       |
'-----------------------'

All components of the LDS interact with each other
indirectly via GW don't they?

Does this diagram illustrate that?  TBH some arrows
would be nice in that to show that RM CM and SM
communicate with each other and the PortManager - 
so they don't look so isolated.

Cheers,
Chris


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