geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [RT] Component Management Principles
Date Wed, 13 Aug 2003 15:42:32 GMT
[RT] = Random Thought

A tradition of the Avalon and Cocoon developers (hopefully it will catch on
here as well).

In the discussions surrounding JMX as a kernel and all the wonderful things
that JMX does for you, I caught a major red flag for designing the kernel.
I have been writing, testing, and working with component containers since
1999 so I have some understanding on the subject.

The red flag came in the form of the concept that components might want to
manage other components.  This is, in my experience, asking for trouble.
COP (Component Oriented Programming) extends the principles you learned in
traditional OOP, and requires that you focus on a subset of those principles.

The way components and containers work with each other are that Containers
provide the entire environment that components live inside of, and does
_all_ the management of the components.  The approach not only enforces
proper IOC, but it simplifies the implementation of many types of things
from security management to interceptor heirarchy, etc.

There is the concept of the Containment Pattern for components.  In other words,
a component can in turn be a container for another set of components.  The
heirarchical model makes it easy to turn on and off whole subsystems, or just
parts of them.  It also simplifies management overall.

The proposed view of using JMX to manage one component from another component
is a dangerous concept due to the potential harm that a trojan component can
do in such a system.  Sure you can argue that JMX provides a security model
to make sure that only certain components can call certain methods.  However,
such arguments fall short when dealing with real life.  How many of you tinker
with the security policies for your servers?  How many of you simply use the
AllPermissions to make life easier on you?  The fundamental problem is that
abusing components in this way violates principles of architectural security.
There is no true security, but there are steps that can be taken to maximize
security.

Always use the principle of least trust.  Start out with the most restricting
settings, the most restricting way of doing things, and only open things up
when it is absolutely necessary.  That way all potential security holes are well
documented and can be avoided.

Also, allowing arbitrary components to manage each other leads to a chaotic
system that is near impossible to understand the expected interactions much
less measure the actual component interactions.  The approach lends itself
more to "emergent" processing rather than planned processing.  While emergent
sounds cool, it is a major maintenance nightmare.

My suggestion is to allow for heirarchical containment models (not as uncommon
as you might think) and only allow containers to manage components.  That will
make things alot simpler to develop and debug, as well as enforce a predictable
security model.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



Mime
View raw message