Markus is all praise about my components definition.   Wew!  I'm glad, I was hand waving a bit, fortunately someone else concurs.  Anyway, he mentions the book "Component Software - Beyond Object-Oriented Programming".  I've seen the book before, however I didn't buy it.  Meaning, I didn't shell out the money and also I didn't agree with the title.  However, I'm a bit uneasy that I haven't read the book.  He could just possibly had some insight that I may have completely overlooked!

Luckily, there are searchable and viewable stuff about the book on the web.  Most interesting are the set of articles "Beyond Objects".  The sad thing however, is that its even more gobbledygook. Bruce Powel Douglass writes in one article:

In past columns, Clemens Szyperski and Bertrand Meyer have raised some interesting and important issues regarding what constitutes a component, but they haven?t reached individual conclusions, let alone a common one. I won?t offer the final word in this column, either; nevertheless, this is a vital debate, so I?m throwing my virtual hat into the ring.

He ends with this definition:

A large-scale executable object designed to be easily replaceable as a unit in the context of a system. 

Okay, a nice general definition, all the critical elements "object", "replaceable", "context of a system".  It covers my definitions earlier.  However, how could this definiton be "Beyond Objects"?

Here's what I can recognize.  There are constructs that are layered on top of objects, design patterns, frameworks and aspects are examples of these.  An implementation of a component model, is a set of design patterns or aspects that are used to achieve the above definition.  Specifically, these should exhibit the characteristics I have described earlier.

[UPDATE] Apparently there's a  2nd edition, published 2002, looks like there actually might be some meat in this book, time to open my wallet then.  Fortunately, according to the preface of the book, there's more than one definition.