[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Vrs-development] CMM Messages

From: Chris Smith
Subject: [Vrs-development] CMM Messages
Date: Fri, 1 Mar 2002 10:52:28 +0000

On Thursday 28 February 2002 22:17, Bill Lance wrote:
> I think this groups the messages into type, where each
> type has a diffent set of needs for formating and
> packaging the message packet.
> How would GW address this grouping?

You're keeping it quite high-level, which is good.

Server Layer Messages
  These will just be GWService calls between services
within an LDS.

Cluster Layer Messages
  These will be GWService calls from a GWServer component
on one LDS to GWService on LDS remote LDSs.

Mirror Block Layer Messages
  Again these are just GWService calls from a GWServer
component on one LDS to the relevent GWService on a
remote LDS.

Any more?

BTW, I've solved the issue of annonymous GWDomains.
Basically I won't introduce annonynimity into Goldwater,
but provide an API where GWDomain entries in Goldwaters
namespace may be removed AND added.
So, the application you build over Goldwater adds and
removes GWDomain details to Goldwaters runtime config.
Goldwater needs to be configured with an upper limit
of GWDomains it can know about at once, can be configured
to know about a set number of 'fixed' GWDomain machines
and the empty GWDomain slots can be filled in by the
application as it sees fit.

So an LDS would contact another LDS (I was thinking via
the webService access port because that's the public bit)
and 'subscribe' to the VRS.  If accepted, it's GWDomain
details would be added to Goldwaters runtime config.
The complicated bits are:
  1. Sending the new GWDomain details to all other
     LDSs in the cluster.  How quickly does this have
     to be achieved?
     This again comes down to having a Subscribe and
     Publish protocol available.  More work for me....
  2. Facilitating the initial connection from an
     unknown LDS.  I'd like it to be GWService call
     really, but that could be potentially dangerous.

Ho Hum

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]