[Aglets-users] RE: Basic Aglets.net Effort

[Thomas C. <ald...@ph...>]

Robert

"A dynamic page would be more fun. <g>  I had a similar concept for
monitoring
the other servers.  Monitoring would be done by remote message sending, but
I
was envisioning a "pull" or "polling" model.  It generates more net traffic
(a request and a respone), but allows the monitoring agent to throttle the
number of responses.  Plus, if for some reason the montior goes down, the
other servers aren`t sending out useless traffic.  I can see some security
precautions being implemented here as well.  For example, raise a warning if
your getting responses when they weren`t requested."

The polling model is persuasive for throttling and bandwidth savings when
the monitor is down. Also, proactive security is better than defensive
security. Let us step through requirements and possible implementations and
see where it takes us:

Requirements: Let's assume for simplicity sake that the monitoring aglet has
a working JDBC connection to a local database and a website is serving the
aforementioned dynamic list. The requirements on the aglet side are clear:
The monitor must confirm that distributed servers are active within a
certain time span. The monitor must be able to exchange aglets and/or
messages with distributed servers. The _process_ must survive either or both
of the monitor server or any distributed server restarting or being
temporally isolated from the network.

Possible Implementation: Regardless of whether the model is "pull" or simply
"receive," a monitor aglet and a distributed server aglet exist. The monitor
is easy - we simply start the Monitor aglet on the monitor server. The
distributed server is slightly more complicated - the server administrator
downloads the code of the Reporter aglet and creates it in the context to be
listed(*).

In this system, the Monitor cannot know of distributed server URLs prior to
first communication without manual intervention. It is the responsibility of
the Reporter aglet, which is coded with the fixed URL of the monitor, to
_initiate_ communication with the monitor. Messaging is preferred to sending
aglets for each update due to bandwidth and processing constraints. Thus
both the Monitor and the Reporter are stationary aglets.

AFAIK, we cannot send a message to a context without a remote proxy to an
aglet in that context. Reporter aglets cannot, upon creation, start sending
messages to the atp://monitor.aglets.net/monitor context of kinds that the
Monitor subscribes to within that context (please correct me if I am wrong).

However, in the Monitor context, we can set a context property "monitor"
with an argument of the AgletProxy for the Monitor. Using the MasterSlave
design pattern, the Reporter could implement a slave (ReporterSlave) that it
sends to the Monitor's context. The slave simply carries the AgletProxy of
Reporter. When it arrives at the Monitor context, it gets an AgletProxy to
the Monitor from the "monitor" context property and passes, by message, the
AgletProxy of the Reporter that spawned it. The ReporterSlave is then
disposed.

Now the Monitor, with the AgletProxy of the respective Reporter, can start
polling that Reporter using predetermined message kinds.

*Alternative Implementation: Per your comments about a sysadmin
configuration form, perhaps it is simpler for system admins to fill out a
one-field form with the URL (e.g. "atp://host.domain.com:4434/context"),
click on submit, and the _monitoring server_ sends out a MonitorSlave aglet?
Implementation is slightly more difficult on the monitor end, but it gets
rid of the need for the messy ReporterSlave pattern and installation (the
MonitorSlave is instantly ready for polling through its proxy at the monitor
upon arrival at the distributed server).

I am leaning towards this alternative as the initial implementation after
walking through the above. If we do the alternative first, the former
implementation is still useful at a later date if we want to roll a
distribution that registers itself with the monitor upon startup. I'll stop
here before going into the recovery process on restart or network isolation.

Your thoughts? Cheryl? Others? If you are reading this, you are probably a
potential user of this, so what works best for you?

Tom (Calivera)