avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] structural evolution
Date Thu, 25 Sep 2003 07:56:55 GMT
On Thursday 25 September 2003 00:11, Berin Loritsch wrote:
> http://sys-con.com/java/article.cfm?id=2201

I would say the article is "brief" at best.

Since I have worked a lot with Jini, I have a rather deep understanding of 
what he is trying to portray, but the important message is not really coming 
across, IMVHO.

1. Jini "removes" the dependency tree, in that a well-behaved services/clients 
"uses" other services, not "depend on" them.

2. Once the Jini infrastructure is set-up, and proper implementation of 
ServiceID, equals() and hashCode() for the service development is done, the 
deployment becomes very fluid. Noone cares where things are running, 
typically noone have a clue.
Getting it to run properly first time is hard.

3. Registering the MBeans in the Jini Lookup Service is a pretty novel idea, 
but IMHO it is not enough for managability.

4. The article says that Reggie must run as an Activatable object. Not 100% 
true. I used to run the transient Reggie, which only takes a couple of lines 
to create.

Now, managability goes a bit further than figuring out what is running. I had 
a ultra-thin "kernel" in each machine, that only new how to download and 
start the Bootstrap service from a "known" web server.
The Bootstrap service, OTOH, was a Jini capable service, that would request 
the Management Service from the Jini LUS, and ask that service what should be 
run on this particular machine, identified by IP number only.
The Bootstrap would then obtain the codebase, and download the service code 
and shoot up all the Jini services from there.
After that the Bootstrap would regularly query the Management service for 
versions, and upgrade the Jini services if so...

Thanks to Jini's principal of serviceAdded/serviceRemoved all clients all had 
to handle that services comes and goes, and if shutdown, they could pick up 
another instance elsewhere.

Also, I didn't use JMX, I have my own version from way back in -98 that I 
prefer, but works very similar. The Management Service had hooks to the 
"Agent" in each service, and could provide very good views of what was going 
on in the same service on different machines, comparing loads, comparing 
versions, and centralized upgrades.

All-in-all, once in place it is marvelous, but not easy to get it up and 

God, I miss that system.... ;o(


P.S. The BootStrap service was designed to "fallback" to download (from the 
"known" web server) and start the Management Service if it wasn't found on 
the network, to avoid chicken-egg...

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message