You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/30 10:05:44 UTC
[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).
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).
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
Cons:
* Tighter binding between .sar and kernel
* Privlidged .sars may become bound to specific kernel implementations
* Requires the interfaces to be placed in shared jar
* 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?
- And thus where do we make the services available? in ComponentManager or
via BlockContext?
- 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>
or some other form?
- Which Kernel components should we export? Deployer seems like a candidate
as does MBeanServer, 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [phoenix] RT: Kernel Services
Posted by Stephen McConnell <mc...@osm.net>.
> > How do you see making a privileged .sar or block? ...
> "privileged" is more like "trusted"!
>
> yes - thats sounds better.
Trusted is the wrong term here - placing trust is something
is an action I may take following consideration of the risks
implied by the action. In this context the term "privileged"
marks a block or sar as an entity which presents a different
risk profile than a non-privileged entity.
Cheers, Steve.
Stephen J. McConnell, OSM sarl
digital products for a global economy
http://www.osm.net
mailto:mcconnell@osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] RT: Kernel Services
Posted by Peter Donald <do...@apache.org>.
On Sun, 30 Sep 2001 19:48, Mircea Toma wrote:
> > 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.
yep ;)
> How do you see making a privileged .sar or block? ... "privileged" is more
> like "trusted"!
yes - thats sounds better.
> > Cons:
> > * Tighter binding between .sar and kernel
> > * Privlidged .sars may become bound to specific kernel implementations
>
> Not if the interfaces are well defined!
true - I don't think we are close enough to having standard yet.
> > - 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?!
works for me !
> > - 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.
kool.
> > or some other form?
> > - Which Kernel components should we export?
>
> ConfigurationRepository?
Perhaps - the interface currently exposed isn't that useful atm. So it would
nee reworking. I was planning to make make it possible for blocks to modify
their own configuration via the BlockContext in the future.
Adding ConfigurationRepository would allow one block to manage multiple other
Blocks configurations (some of which may be in different SAR).
> > as does MBeanServer,
>
> -1
>
> I see the MBeanServer and even the SystemManager outside the kernel.
> SystemManager can act as a facade to kernel services.
Thats one way of doing it. In which case the kernel would need to add in some
naming services (JNDI) that is accessible.
The one thing that makes me nervous about this is that would mean that Blocks
would have to implement their own management interface. A while back someone
suggested that we have the "manager" object/MBean sit side by side with real
object (partially acting as a wrapper/adapter). By doing it this way we would
not have to pollute real task with management stuff (ie all the extra
getter/setter methods) that often increases surface area of object.
Anyways something to think about.
--
Cheers,
Pete
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] RT: Kernel Services
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] RT: Kernel Services
Posted by Pratik Patel <pr...@metalab.unc.edu>.
>
>
>- 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?
>
I belive we should keep blockinfo as atomic as possible and also
self-contained - hence when a "block deployer" opens a block it can
discover what dependencies are needed to make the block work.
>- And thus where do we make the services available? in ComponentManager or
>via BlockContext?
>
At this moment in time I believe this should be done at the BlockContext
if possible.
I think of components as smaller modules, and Blocks as larger modules
made up of components. I suppose this depends on the deliniation between
blocks/components, which may be a grey area: A JDBCPool module is
clearly(?) a small service which is used to access a larger service like
a DBMS (such as HSQL). JDBCPool = component, DBMS = block. I'm not
convinced that this is the correct way of thinking, however.
cheers
Pratik
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org