On 12-11-10 12:00, Tom Hobbs wrote:
So I was wondering if that is still the consideration of the
community. I'm proposing writing something along the lines of a
"VmAdmin" to provide some of these features. In the example I gave
above, we implemented these things by adding additional methods to the
service interface, but it would have been a better solution to have
them in the infrastructure.
To recap what i understand until now:
You want to include code, that presents itself as a service, and
provides telemetry about a vm.
If thats the case no objections. I like the idea of more telemetry. JMX
is implemented with remoting. So if we divide the problem, whe have the
telemetry hooks into the jini kernel, and the transport.
JMX can have all kind of transports, so if you model it a bit like
MBeans we can later add a jini based JMX agent to it. Currently i have
RMI based JMX transports in use, and i don't like the firewall issues
with RMI. I would be very nice, if there is a service for every VM where
you can get your JMX data from.
And if you export all the MBean look-a-likes through a central method,
you can cook whatever security model you like there.
Where do you expect you want to amend the jini apis?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
