avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Date Tue, 25 Jun 2002 13:09:47 GMT
> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> Playing the stubborn role at least brought some unification 
> back, which is a good thing, no matter how much my ego is 
> satisfied with the resoluzion :)
> No, it is clear now and it was clear before, just that I do 
> not perceive 
>  lookup(role,hint);
> and
>  lookup(role+"/"+hint);
> to be architectrually equivalent since they represent two 
> different cognitive ways to access to components and we loose 
> completely the ability to match a role to a java interface.

Stefano.  There are several component architectures in existence.
Each one of them has the concept of lookup, container, component,
and client.  This is true of CORBA, COM, EJB, Servlet, Avalon,
etc.  The one thing that is different about Avalon from all the
other component architectures is the lookup.

The other component architectures *bind* components or component
stubs to a namespace.  That namespace can be hierarchical (i.e.
use directories), or flat.  EJBs and Servlets use JNDI.  CORBA
uses the COS Naming Service.  COM uses another mechanism (I am
not as familiar with that).

Everywhere we need to use constraints (i.e. hints), it is usually
done from a container/component.  The hybrid container/component
acts as both a container and a component.  Take advantage of this
fact, and access the components you need directly.

> While using java interfaces for metadata is a limited 
> approach, at least it allowed stronger typing. The same can 
> be said for 'role = interface'.

However, it causes problems with inheritance.  Consider if you
will something that until I brought it to the Cocooners attention
was rather common.  An abstract base class for component
implementations implements the ThreadSafe interface.  A concrete
implementation that extends the abstract class implements the
Poolable interface.  So which is it?  Because of this fiasco,
we were forced to put in some checks that would throw an exception
if there were multiple LifeStyle interfaces implemented for a

We were also forced to adopt the practice of not declaring lifestyle
until the component was concretely implemented.  The inheritance
of lifestyle seemed like a good approach at first, but it caused
more problems than it solved.

Not to mention it is difficult to authoritatively say how the
component would be treated in the container.

That is why Fortress, Merlin, Phoenix, et. al. declare the lifestyle
and other meta information in the component descriptor.  The
developer can say with confidence which creational policy (lifestyle)
was used for their component.  There was less ambiguity and less
chance for inheritance causing problems.

Furthermore, with the role = interface issue in over half of the
cases it is sufficient.  However, the container has no way of
knowing what the component needs in terms of external components.
By using meta data, we can implement a more *secure* system by
only allowing a component to see the external components it
needs or is registered for.  As it is now, a component can freely
try interface names to attempt to control or cause internal DoS
attacks because role=interface and there is no scoping of what
the component can see.

We can develop a far more secure system that is more architecturally
unfriendly to deviant components that might be loaded in at runtime
because role != interface, and the component can only see what it
is allowed to see.

The container can have the needed control to provide a secure

> Anyway, since it seems like I'm the only one having such 
> vision, I'll shut up and let you guys do your job.

Don't sound so defeated.

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

View raw message