Enhanced EJB Architecture

I chanced upon the Enhanced EJB Architecture prototype at ObjectWeb. It's an attempt at introducing a more comprehensive component model for EJB:

The main goals are: multiple interfaces for components, provides/requires specification of components, hierarchical component architecture and configurable component behavior. In this model, components can be constructed with better reusability, can provide functionality with finer granularity and improve cooperation between components.

Don't dismiss this as yet another piecemeal attempt to fix the deficiencies of EJB (see EJB 3.0). Apparently, there are serveral leading edge ideas that are being brought into focus by this research.

The interesting thing about this research is that it takes a step back and looks at the big picture. The big picture is, how can we enhance EJB with a reasonably effective component model. The research studies contemporary component models and draws from the latest in reseatch on component models.

The proposed component model consists of a set of provided (Provides) and require (Requires) functionality in the form of a behavior descriptions. Provides and Requires are composed of three types, a method interface, an event interface and a named-value interface.

What I find interesting about the work is the emphasis on including "Requires" as a definition of a component and the named-value interface as means of shared data and configuration. What people tend to forget is that the getter/setter methods in javabeans serve as a means of configuration of a bean at design time. It's all too often also confused with the usual usage of object attributes, a clear distinction of the difference is tends to be beneficial. (Interesting, this seems in agreement with my Demeter speculation)

I think it's a little earlier to piece together a more comprehensive component model, however it seems that it's getting close. My hunch is that when you understand instance based configuration and then you combine it with Fluid AOP (i.e. instance based AOP), you'll be on your way to a more flexible, reusable and manageable component model. But that's just a hunch, but something worth keeping in tha back of your mind.