> 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. 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 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
