In particular, a component:
- Identifies functionalities of a system as a set of provided interfaces, and dependencies as a set of required interfaces,
- Required interfaces are bound to provided ones to resolve a dependency,
- Can be implemented as a monolithic entity (aka atomic/primitive) or as a composition of components,
- Can be reused and deployed independently.
And that's it!
A lot of clever guys have been working on the description of what component are or are not. Thus, when I read the description of these new approaches, I am so disappointed to read the same story again and again. I mean a cat is a cat and a dog is a dog, so why do they ignore these principles and just try to reinvent the wheel? I definitely have nothing against implementing yet another component model that supports some interesting features, but I am very uncertain about presenting it as a radically different approach, because most of the time I find it misleading for the reader.
However, I do believe in extending these lightweight component models (e.g., Spring, Fractal, OpenCom) that have been successfully applied to develop systems made of different component granularities, from operating systems to application servers and applications. In particular, Fractal and OpenCom are now applied to build protocol stacks and network routers that exhibit advanced features, such as self-configuration, self-healing, self-adaptation, self-optimisation.
So, why people prefer to develop their own limited framework rather than collaborating with existing approaches to make more interesting things happen?
