----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Avalon Development" <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 2:05 AM Subject: [phoenix] RT: Kernel Services
> Hi, > > Heres just a random collection of thoughts on about the feasability of > allowing access to Kernel services such as > * Deployer interface > * Kernel interface (and thus Application interfaces) > * Embeddor interface > * SystemManager interface > * MBeanServer interface > * LogManager interface > * ConfigurationManager interface > etc. > > from within a Sar. > > Making these interfaces available from a .sar makes it much easier to > implement certain features in application land rather than kernel land. For > instance you could implement a JMX agent, DeployMonitor or other similar apps > in application land rather than kernel land. The advantage of this being that > you have access to all Cornerstone services + other Blocks which makes it > easier to develope. > > So lets say you wanted to create a Agent that monitors MBeanServer and > exports it via telnet, as a webapp, RMI or via some other system. Currently > you would have to write it in Kernel space which is a bit painful and doesn't > allow reuse but if it was in application space you could easily use > Jetty/Tomcat or whatever to run webapp, jtelnetd to run tlenet daemon or > whatever. And things become much easier (just drop .sar file into ./apps to > enable agent). Yes, that's cool but the kernel level interfaces have to be stable then. > > There are negatives. Allowing access to such services creates a higher > coupling between the .sar and the kernel. Thus it makes it harder to evolve > the kernel and any "privlidegd" .sars (ie those who have access to kernel > services). How do you see making a privileged .sar or block? ... "privileged" is more like "trusted"! > > So... > > Pros: > * Easy to enhance functionality of kernel by adding a .sar rather than > modifying kernel. > * Application space is easier to work in. > * Application space makes components more reusable > * Easily have multiple implementations of same "functionality". ie one SNMP > Agent and one Web based management agent Hence a standard service distribution! > > Cons: > * Tighter binding between .sar and kernel > * Privlidged .sars may become bound to specific kernel implementations Not if the interfaces are well defined! > * Requires the interfaces to be placed in shared jar Reasonable requirement! > * We may have to do extensive guarding of threads in future (though not for a > while) so that each Application and the Kernel all have different > ThreadGroups. > > So if we do decide to add this there are some open questions: > > - Where to we declare a dependency on Kernel services? Do we declare it at > Block level or at .sar level ? ie in blockinfo files or assembly files? in blockinfo files as kernel-service?! > - And thus where do we make the services available? in ComponentManager or > via BlockContext? ComponentManager would be the natural choice, kernel level services have roles and are also Component-s. > - What should format of dependency look like? ie > <kernel-services> > <service name="org.apache.avalon.phoenix.interfaces.Deployer" > version="1.0"/> > </kernel-services> > or wither other dependencies in blockinfo > > <dependencies> > <kernel-service name="org.apache.avalon.phoenix.interfaces.Deployer" > version="1.0"/> > </dependencies> +1 > > or some other form? > - Which Kernel components should we export? ConfigurationRepository? > Deployer seems like a candidate +1 > as does MBeanServer, -1 I see the MBeanServer and even the SystemManager outside the kernel. SystemManager can act as a facade to kernel services. > perhaps Embeddor aswell (so jesktop can shutdown phoenix > gracefully) > - other factors? > > Thoughts on any of this??? > > -- > Cheers, > > Pete > > *----------------------------------------------* > | The best defense against logic is ignorance. | > *----------------------------------------------* > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
