Berin Loritsch wrote:
>
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> >
> >
> > 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
> component.
Great point, I missed it before.
> 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.
Ok, I'm sold.
> 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
> environment.
>
> >
> > 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.
Ok, got your points: I'll follow you guys.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
