Component Patterns - Architecture and Applications with EJB


News: Component Patterns - Architecture and Applications with EJB

  1. Hello Component Folks,

    We have seen some discussion about patterns in the context of component
    architectures on this page recently. Also, several people are working on
    books, etc. about the topic. To add to that, we would like to
    annouce that we are also writing on a book on this subject.
    It will be called "Component Patterns - Architecture and Applications with
    EJB" and it will be published in Wiley's Pattern Series in the first half
    of 2002 - we started working on the book in December 2000.

    The book teaches the advanced enterprise component developer the deeper
    foundations of EJB systems and explains how to build efficient
    EJB-based applications, using patterns and concrete code examples.

    The book will be made up of 3 major sections.
    1) A pattern language (already mostly written) that explains the
    foundations of component based systems, comparing EJB, COM+ and CCM in the
    examples (an early draft can be found on TheServerSide, a more recent
    one can be found at
    2) Concrete examples (with code and UML) to see how the more general
    patterns from section 1 apply to EJB and what this means for the developer.
    3) A collection of about 20 patterns that help in building component based
    appliations, some general, some specific to EJB. This section contains the
    rationales of when each pattern should be applied and provides concrete
    examples using Java/EJB code and UML and how these patterns can be applied
    to EJB projects. We do not cover non-EJB-parts of J2EE.

    The pattern style is Alexandrian throughout the book.

    The book, as we pointed out above, is currently being written. As soon as
    we have material ready for review, we will let you know through this
    forum. You will then have the chance to review the material.

    For more information contact us at markus dot voelter at mathema dot de

    Markus, Alexander, Eberhard

    Threaded Messages (52)

  2. Hi there you old component folks.

    You're making progress I see, so way to go !

    But I take advantage of this thing to provoke a discussion, although I might raise a flame war here.

    You're pattern language has "Component" all over the place.
    Inspite that you fail to give any definiton, let aside
    "Decompose your application into several distinct parts called components."

    Well can you clear the mistery and try to give us a definiton of what a "Component" might be?

    Hint, I learnt about components since I first time installed Delphi 1 for Windows 3.1, and since EJBs and other cool stuff like that on the "server side" the component become a big buzz-word but the fact is that the definition was always forgotten and became such a loose conceptthat catches everything for everybody.

    If the actual perception of the component is to prevail, I'll declare the "stdio.h" together with the associated object file a component ! I hope not.

    Such old component folks like you should be able to try a definition.

  3. Hi Costin,

    I knew that you would be one of the first to reply :-)

    No, we are not attempting to define a component, formally.
    But there are two interesting points in this respect.

    If you take a look at the introduction chapter, we outline
    what the book will NOT be about. And it lists things like
    GUI Components (OCX, VBX, M$X), and Application subsystems
    (like the SAP CRM "Component"). And by reading the principles and taking a look at the patterns in the language, a component is implicitly defined by the way how
    "component" is used in the context of the language.

    The charcteristics of a "Component" as we use it are:
    - coarse grained
    - accessible remotely by an interface and a component bus
    - Separation of Concerns: Has to run in a container
    - has some functional variability

    So, while not giving a formal definition, we give a
    set of characteristics that each component has to exhibit.

    Waiting for your reply :-)

  4. I knew you could have use more help in making a conceptually strong case for the components.

    You should try to provide a definition at least of what a component is in your vision.

    Of the things you mentioned I propose we should eliminate "accessible remotely by an interface and a component bus" exactly because of the separation of concerns.
    That's exactly one of the many mistakes in the new EJb2.0PFD2.

    Whether a component is access remotely or locally should be orthogonal on how you write a component or on what a componet might be.
    The system should be smart enough to propagate calls, provide the components locally when it makes sense for performance etc.

    With the other three let's look at <stdio.h>
    - it runs in a container, the C runtime, ultimately in the OS.
    - coarse grained, of course
    - functional variability, yes, if you look at sprintf(...) you'll know it's has "functional variability"

    I could add it has a clear separated interface and a lot of other very positive aspects.
    What's that that differentiate components from other software artifacts like frameworks, libraries, etcc...

    So one might think you abuse of "component" because it is a well regarded buzzword and may provide legitimity to some things that are not really components.

    The essential quality that is missing can be found exactly in what you say you don't talk about: in VBX,OCX, M$X and I would add Delphi VCL, so maybe you should pay attention to them even if you don't talk about them.

  5. Hi Costin,

    could good old CORBA shed some light on this discussion :)? Well, let's try:

    . a component is a piece of code accessible through (and only through) an interface;

    . a component must have a property that's sometimes called *location transparency*: in other words, a client should access it in the same way, no matter where the component is physically located;

    . the above property implies the existence of an object bus/broker/smart container as the component, *in the general case*, will be remotely located in respect to the client (in my opinion, the collocation of the component and the client should be seen as the exception, not the rule).

    I know you would surely remove the third point of my tentative definition but... what would you add :)?

    Hope you won't answer that a component must adhere to some binary format to qualify as such ;).


    cristina at acm dot org
  6. Hi Chris,

    I don't want necessarily to disagree with you but:

    You just gave a characterization of the distributed object model as outlined in the CORBA spec long time ago and as it is currently now.

    Please note that they use the term "Object" and CORBA is acronym for the Common OBJECT Request Broker and not for component bus or anything like that.

    So we could say at a limit that every distributed object as in CORBA is really a component and get away with an easy definition, but it would be like we make an abuse of the word.

    I think we really owe to the wonderful guys who created Visual Basic and Delphi (they really revolutionised the industry and made Component Based Programming come true) not to abuse this notion and exclude their work from it.

    So what do VB controls, VBX, ActiveX, Delphi VCL compoments and JavaBeans (those being the obvious examples of components) have in common and make programming easyer and far more productive then it was before ?

    My thinking goes that while they have a clear interface they're more or less self contained as a distribution unit, they certainly have to live in a container (figuratively we all live in a container), they are not required to be distributed and certainly not required to be on any bus.

    But the essential feature in my view, and I'd very much want to here your comments about it, is that they are amenable to being used by programming tools such as IDEs.

    They all have at least two life cycle, the "deisgn-time" and the "run-time" and the two states are clearly defined in their contract.

    For many of them you really don't need to write a single line of code (nor a line of code be generated by the tool), you use a property inspector, you connect them to other components by events amd properties and voila , they work.
    They even interact with the IDE to provide dialogs who guide you to set up more complex properties.
    You can even preview their runtime behaviour in the design time IDE.

    Their design time state is persisted by the IDE andwhen they are activated the runtime makes sure they get their persisted design time state.
    JavaBeans are an unfortunate exception to this rule since their design time state is saved in source code being generated and this has some bad consequences.

    Of course you generally also have the flexibility to code against their interface, but the fact is that programming in code is way too repetitive and boring for us to afford to disregard that many tasks can be done in an easier way.

    Please note that I'm not talking only about UI components here,since in Delphi, VB you can manipulate also non visual components like database queries, corba proxies,http connections socketsand tons of other stuff.

    I know my definition may sound controversial because it would rule out stuff like EJBs (for now) from the component world, and Sun's Componet Based Development flag with regards to J2EE may look like a marketing lie (which it really is) .

    But what do you think ?

  7. Hi Costin,

    I think you're absolutely right about components and IDEs: a true component can be configured and wired at design time under an appropriate IDE. We both are talking about visual (GUI) as well as non-visual components, of course. I'm not sure that design time state should always be persisted by the IDE, though: including such a state in the generated code may avoid dependencies between the component and the IDE... Doesn't that look like a good thing to you?

    As a matter of fact, there are no such IDEs for EJB right now. In my opinion, they don't exist because there's no demand for them. As you may know, Together/J and WebGain, among others, offer some support for EJB design time configuration using UML. Problem is, developers are not that eager to work with them :-).

    Let me remind you that VB and even Delphi were sold as tools for "non-programmers"... Well, we both know there's no such thing like a good application developed by a non-programmer. Marketing pitches can be powerful, however. EJB developers just don't want to be seen as VB or Delphi programmers.

    Even so, I believe full-fledged EJB IDEs may well exist in the near future. If there are none today, this doesn't mean EJBs don't qualify as components: they comply to a component model that's just different from early ones. It's different probably because it has been, from the beginning, a distributed and platform-independent component model.

    Distribution, as I've already noticed, will be the rule, not the exception: just think about the P2P models that are showing up lately. Sure I think we should appreciate and learn from early component models. Anyway, they can't be seen as complete, definitive models... We still have a long road ahead.

    How much do you disagree this time ;-)?


    cristina at acm dot org
  8. Well,

    >How much do you disagree this time ;-)?

    A little bit. But we're getting to common ground :)

    > EJB developers just don't want to be seen as VB or Delphi > programmers.

    Well, that's what in French it's called inculture (I don't know in English).
    I'm very proud of my Delphi programming past, although I'm not exactly an EJB programmer, but I'm proud of that also :)
    As a matter of fact the later versions of Object Pascal are a much better language then Java from the OO point of view.
    Too bad I can't find somebody to pay me for Deplhi programming as much as I'm paid for Java programming :(

    > I'm not sure that design time state should always be persisted by the IDE,

    Because it's not persisted in JavaBeans then when you move your generated code from one IDE to another the later is not able to parse back the design time state !. So you're kind of stucked.
    It happened to me even between two versions of Visual Age.
    Code generation is not a good option because it's pointless (and not that feasible) to reverse engineer source code in the next design session.
    If the design time state is well specified in the model and serialized we wouldn't have this problem.

    In general reverse engineering on source code happens because we don't have better models for code construction.

    Anyway this is a rather technical problem, the important thing in the big picture is that without design-time state there could be no component.

    >Distribution, as I've already noticed, will be the rule, >not the exception

    I disagree here.
    Distribution should be the exception not the rule.
    There should be more non-distributed components that will help the only few distributed components per system do their work (implementation).

    In the end I'll refer to your argument that EJB's should be regarded as components.

    I don't want to disagree with you until I see your logical argument.
    According to the definition you previously provided every CORBA object would qualify as component.

    So what qualify EJBs as components ?
     You said they comply to a component model, which is that model, I'm trying for quite some time to find out what exactly is the component model for these EJBs ?

    >Sure I think we should appreciate and learn from early component models.

    Well, I think we shouldn't try to be condescendent with previous work because I'm not sure if we work with better models now.
    It was also what happened with OO databases which looked at relational model as something passee and they hit their head into the wall pretty hard.

    I think a little defintion of what is a component in this supposed component model would suffice :)


  9. I think Costin's last comment says most of it.

    That any of you agree is quite interesting, since I think you are looking at things from different angles. There's nothing wrong with that (in fact it's very important in discussions such as this) and note I said I THINK, so don't beat me up OK! :-)

    Costin is looking at this as through a developers eyes, I think (you do talk about the ability to tie things together in the IDE and the related concepts.)

    Markus is talking more about the design of systems. The two are not radically different but they can subtelly alter the view of some things, such as this.

    I was thinking about this earlier, from the perspective of a user (I.e. someone who buys the product you wrote, so they are still technical.)

    From my mind, if that is who I am then a component could be defined as:

    1) Something that, when I get a new version from the supplier and replace the existing version in my system, all I have to do is drop the replacement in place. The rest of the system doesn't care. (This is easy to translate into technical dialect such as encapsulation, coarse grained, etc etc, but lets not bother for now. Also lets assume in the above example that the supplier is intelligent and makes components backwards compatible!)

    2) Something which has a defined set of responsibilities in my system. For instance, you could view the "authentication and access control lists " of users as a component. Done properly it meets (1) as well.

    3) Something which has a defined set of collaborations with other components. For instance, my authentication component might have a requirement that it can talk to an LDAP component.

    Theres more I could scribble down here, but you get the idea. (I accept you could apply these terms to objects as well, so there is obviously more to include in the definition.)

    The main point I'm trying to make is that if you are going to discuss "what is a component" then you should define the context in which you are discussing it as well. Everyone has a different definition and it's hard for someone to imply meaning from your book if they don't know yours. I agree with Costin here, I think you absolutely must have this section in the book.

    On the topic of distribution, in the example I gave above, none of that was relevant.

    However, if you just re-read the posts on the thread, then I think the following can be deduced.

    The phrase "distributed component" is used. If all components were distributed, then the word distributed would be redundant. Hence, the use of the phrase implies that some components are not distributed. If some components are not distributed then it can't be a requirement for something that wants to be called a component to be distributed. QED. :-)

    I personally think that distributing components is about how you use them, not how you define them.

    As for EJB being component technology. I'm not sure that's particularly relevant. How about this:

    EJBs (I.e. things you develop using the EJB framework) COULD be components (depending of course on how you define them!)

    You could just as easily write things with EJB technology that were not components.

    Just a thought!


  10. Tony,

    I agree that the problem is to be viewed from different angles.
    But it has to be viewed from ALL ANGLES.
    If I as a user of that software artifact don't have a criteria to recognize it as a component, then the thing is
    most likely not a component.
    What you described in your definition also applies perfectly to OO frameworks, even the C standard library !

    So we need to find the closest enclosing type (which is software artifact or software module) and the specific difference, otherwise we failed to know what a component is and arbitrary can occur.
    Componet Based Development is quite a buzz,and many people want to say this piece of software is component based because it sounds so well.
    But not only we need to eliminate confusion, but it's also an ethics issue I think, that we owe to the inventors of VB and Delphi who pioneered CBD on large scale, not to lower their standards.

    We give the component a definition which also could aply to artifacts that are obvious not components.
    And should be obvious that Component Based Development should be a sub-category of RAD - rapid application development.

    What then ?


    P.S. You already use the name "EJB framework" - that's exactly what I think also.
    Maybe Sun could make it to be "EJB component model" if only they had more direction, vision, and a bit of theoretical rigor in what they do.
  11. Like I said, the definition was not precise. While I think about it, it does not seem particularly unreasonable to me that stdio could be viewed as a component. If you look at the authentication libraries in Solaris / Linux etc., they are specifically designed to be plugged in and out. They could also be termed components.

    The odds of getting consensus on what a component is is as near to zero as makes do difference, so the important thing is to give your definition, give the context in which it was made, and disclose your bias (as you did, when you said you were proud of your Delphi background. I've used Delphi too and I like it also.)

    If all that information is available to the person reading your definition, then they have enough to draw their own conclusions on whether they agree with you or not.

    To disclose my own bias, I've _never_ programmed in C, C++, assembler or anything else similar (and I have absolutely no intention of ever so doing unless I have to! :-))

    I have used Java for most of it's life, I've used Delphi since version 2, VB since version 3, shell scripts, perl, SQL etc etc. My main focus is on Java, but then that doesn't exactly make me unique these days. :-)

    As such, I agree, a lot of the CBD world we see today owes it's existense to things like Delphi and VB, which reduced average project cost significantly when compared with C++.

    I think we basically agree with each other here, especially about EJB, about which my most positive statement is "it looks like it has a lot of potential." Whether Sun let it live up to that potential....well, only time will tell.


  12. Bonjour Costin,

    first, just in case I haven't made myself clear: I like Delphi, too, and I don't think it's an IDE for "non-programmers". In fact, I think such an IDE doesn't exist at all. Not today, at least.

    Regarding our discussion on component models, I'll try to answer a slightly different question: why wouldn't an EJB qualify as a component?

    EJBs are accessed by clients through well-defined contracts (interfaces); the EJB server and container are themselves supporting components that provide common services and location transparency; some EJB methods (like finder methods) were even designed to be used by JavaBean-style builder tools... If EJBs are not components, then how do you call them :-)?

    I do agree with you in that EJBs are not, by design, toolable components like JavaBeans. Nothing prevents them to be manipulated as such, however. I've found at least one tool that allows the developer to visually configure and wire EJBs. It supports EJB-specific deployment tasks as well. Please visit:

    Interestingly, the CORBA Component Model started as a language-independent version of the JavaBean (not EJB) component model. If you want to know more, please take a look at Ch. 33 of Orfali & Harkey's "Java and CORBA" book.

    As a final remark, let me remind you that EJBs are not general-purpose components: they are meant to encapsulate business logic only. Maybe that's why it seems so hard to make straight comparisons between them and Delphi-style components. Besides, EJBs are distributed by definition.

    By the way, may I ask you why you don't believe in fully distributed architectures?

    If you think this discussion is getting off-topic, please email me at the address below. If you choose to do so, you can write in French if you prefer.

    Best regards,

    cristina at acm dot org
  13. I won't speak for Costin, but I do have a few comments...

    > EJBs are accessed by clients through well-definedcontracts (interfaces); the EJB server and container are themselves supporting components that provide common services and location transparency; some EJB methods (like finder methods) were even designed to be used by JavaBean-style builder tools... If EJBs are not components, then how do you call them :-)?

    Location transparency only applies to distributed components, and the definition in question was for components. I admit, you shouldn't "care" where any component is (distributed or otherwise) but since you are talking about this in the context of EJB it is essentially a distribution semantic, not part of the definition of a component.

    Also, the description you gave above applies equally well to any well developed Java class. (ignoring IDE wiring for the moment.) They have defined contracts, they are location independent (instantiate it, you don't care which class loader loaded it.)

    I stick by my earlier statement, that EJB is a framework, out of which you _could_ build components. However, if you apply enough "lack of thought" then you can just as easily build things that would never qualify as components. I've seen that done often enough! :-)

    >> As a final remark, let me remind you that EJBs are not general-purpose components: they are meant to encapsulate business logic only. Maybe that's why it seems so hard to make straight comparisons between them and Delphi-style components. Besides, EJBs are distributed by definition.

    There's nothing to stop anyone using EJB as general purpose components supporting a business, rather than the business themselves. In fact, stateless session beans are often used for such purposes (and of all the bean types currently in existence, these are the most scaleable.)

    I used such a bean as the interface into a framework which abstracts a wide variety of disparate data sources (HTTP, RMI, JDBC, FILE SYSTEM etc.) none of which is business logic, it's very much a very thin wrapper over the model. It works extremeley well and has proven very scaleable. My EJB is merely a fault tolerant load balanced facade into multiple instances of this framework. I have others (a servlet for instance.) Without going on for ever, this shows how you can quite easily use EJB for things that have nothing to do with business logic. It's a matter of application of the technology, not the definition of it.



    PS. I don't recall Costin saying he didn't believe in distributed systems. :-)
  14. Hi Tony,

    thanks for your comments. Of course, EJB can be viewed as a framework: you have the server/container and well-defined contracts to talk with then. You write your code as a component so the framework can call it whenever needed. Seems perfect to me.

    This notion and that of an EJB as a component are not mutually exclusive, though. It looks like our discussion is not converging because our initial hypothesis is not the same.

    You see, no component technology can help you when you don't know how to design a component. In other words, if you don't know what to put in your component, your code won't qualify as one whatever the language/framework/IDE you may be using. I'm assuming that a developer knows how to design a component in the first place... It looks like you and Costin are not so sure about it :-).

    Regarding the application you describe, I wouldn't use a session bean to implement the facade, unless there are transactional functionalities behind it. If this is not the case, I would use a servlet instead.


    criatina at acm dot org
  15. In the context of the application I described, a servlet is too loosely coupled and too expensive (cost of forming socket level connection all the time)

    Also, I can't propogate exceptions across HTTP, I have to convert them to error codes etc.

    A stateless session bean is fine for this type of work, even though there are no transactional requirements, and it gives much higher performance for the client applications. The return from the facade is an org.w3c.dom.Document. Using the HTTP approach this would have to be reparsed into said object by the client, which kills performance. The EJB facade is approximately 3 times faster. Servlet is therefore only used for non Java clients.

    Anyway, this is all very off topic so I won't talk about it any more.

    Given some of the code I've seen in my travels, I think it's a very brave assumption to think that all developers know how to design components. I don't want to beat up on people, there are plenty of very good developers out there, but there are plenty of bad ones too (A bit like car drivers. :-))

    EJB is really just an abstract set of interfaces. Until you write something with it, it's just a spec. It's what you create with it that may be classified as a component. Perhaps, at a stretch, you could call it a component framework, but theres lots of things in the 2.0 spec that tread on the toes of that, but that's a topic from another thread and I won't go into it here (Costin has plenty to say about it though! :))

    Your main point, which I agree with, is probably the best way to work out what goes into the definition of a component. You said:

    "You see, no component technology can help you when you don't know how to design a component. In other words, if you don't know what to put in your component, your code won't qualify as one whatever the language/framework/IDE you may be using."

    So, if you are designing a "component" what do you have to consider?


  16. Salut Cris,

    >first, just in case I haven't made myself clear: I like Delphi, too, and I don't think it's an IDE for

    Of course you didn't need to make yourself clear, it was clear from your iniitial phrase, even for my not so good English skills :)

    Let's try to get to some common ground.
    Could you please provide us of a tentative definition of what you think components are ?
    I'll have to ask you for a little more this time.

    That is, your definition should make distributed objects like in CORBA and DCOM, distributed frameworks
    (well, I guess you'll start your definition with "distributed" anyway, although I suggested it is an orthogonal aspect after all) and other obvious "not necessary a component" class of software artifacts,
    a PROPER SUPERSET of Components class.
    Or the other way around which is better, can you please provide us with the specific difference that makes the class of components a PROPER SUBSET of the most specific enclosing class of sofware artifacts.

    I guess you know your previous definition failed in this respect :)

    Then you'll se how easy it is to get to common ground when things are well defined.

  17. Costin,
           You do like your maths don't you! We're into group theory and proper subsets and all sorts of wonderful concepts now, reminds me of maths class at school, which I loved! :-)

    I agree (as my earlier set of deductive logic implied) that distribution is orthogonal to components.

    I'm not so sure I agree that components have to be wireable in the IDE, but I think they have to be able to be used configurably, rather than programatically, which I think is a more generic version of the same thing?


  18. Hi Costin,

    yes my definition has failed regarding your criteria. I'll try to be more precise next time :-).

    You and Tony will have to wait a while for a new tentative definition... Never mind, though: our healthy discussion will keep going on.


    cristina at acm dot org

  19. Hi Costin,

    okay, let's try again... This time, I'll start by Bertrand Meyer's thoughts on this subject:

    "A basic reusable component should be a software element (from there we can of course go to 'collections' of software elements). That element should be a 'module' of reasonable size, satisfying the modularity requirements of the previous chapter [Direct Mapping, Few Interfaces, Weak Coupling, Explicit Interfaces and Information Hiding]; in particular, its relations to other software, if any, should be severely limited to facilitate independent reuse. The information describing the module's capabilities... should be 'abstract': rather than describing all the details of the module (as with source code), it should, in accordance with the principle of Information Hiding, highlight the properties relevant to clients.

    The term 'abstracted module' will serve as a name for such units of reuse, consisting of directly usable software, available to the outside world through a description which contains only a subset of each unit's properties.


    It may be acceptable for a module to be distributed in source form but reused on the basis of an abstract interface description."

    From Bertrand's spec of a 'reusable component' we can now establish the differences between a component and other software artifacts:

     . a component *must be a module* satisfying a number of well-defined modularity conditions;
     . it *must be weakly coupled* with other modules;
     . it *must be accessed through a public interface* which hides its implementation from clients.

    The above differences, I think, discriminate a component from other software artifacts. Furthermore, it allows us to draw some interesting conclusions:

     . if a bunch of related functions with well-defined signatures qualify as a module, then a C or FORTRAN library, for example, is indeed a component;
     . since a class is a module, any class (or a handful of related classes) satisfying the other two conditions stated above is a component: as far as I can see, this qualifies an EJB as a component.
     . a 'distributed component' would be a superset of the 'component' category, as you've already noticed; so I'll agree with you and Tony in that distribution is orthogonal to componentization. I do believe, however, that distribution enforces componentization (we can discuss this later if you want).

    If you're interested in the details, please take a look at "Object-Oriented Software Construction", 2nd ed., by Bertrand Meyer.

    So are we now getting to common ground ;-)?



  20. I think we're getting there. :-)

    However I still maintain that it's perfectly possible to write an EJB that does not comply with the rules you lay out.

    For instance, if my bean provides accessor methods that let data out of the bean, which should really be hidden completely. This assumes that data hiding means "Do not let data out of the object without good reason" and not "do not provide direct access to the attributes."

    Obviously some data is allowed out, but I have seen code where a contained HashMap of information is allowed to escape a bean. The proper solution was to add the one method that was needed to to the bean and have it delegate to the HashMap. (In this case, a size() method was all that was needed.) Exposing the HashMap would have caused a lot of issues if I hadn't spotted it. So, this bean, in my opinion, broke the rules you laid out.

    I am fairly comfortable now with your definition as it stands (If Costin is too then I will assume I'm dreaming! :-))

    So what's your view that distribution enforces componentization?



  21. Hi Cristina,

    So you went for an authority, didn't you ?

    Bertrand Meyer is cerrtainly an ace in Design By Contract but I would certainly have liked if he could also "Define By Contract".

    Aside from being very long and fuzzy, Bertrand gave the definiton of module/unit/library as in Stuctured programing.

    From Bertrand's spec of a 'reusable component' we can now establish the differences between a component and other software artifacts:

    So the supposedly specific difference that would make the componet class a proper subset of the enclosing class (what is the most spefific enclosing class, by the way? )are:
     . a component *must be a module* satisfying a number of well-defined modularity conditions;
     . it *must be weakly coupled* with other modules;
     . it *must be accessed through a public interface* which hides its implementation from clients.

    Common, ypou must be kidding me, you knew your definition is weak so you went to the "authority" because yoiu knew I'd have objections.

    So, since aproximately 1968-1970 everybody who programmed properly in 3rd generation languages (C,Pascal, Algol, Modula, COBOL ... you name it ) was doing Component Based Development "avant la lettre".
    And in their ignorance they called their work structured programming until the honourable Bertrand Meyer came to enlighten us that Pasacal Units, C libraries and almost every little decent piece of software we wrote should rightfully be called COMPONENT.

    > So are we now getting to common ground ;-)?

    As I said when things are well defined ...
    I guess you knew they were not.

  22. Hi Costin,

    well, I don't see why you're so upset... If you have read the relevant chapters of Bertrand's book, you know he starts from classical, as neutral as possible concepts in order to build an object-oriented framework for software engineering. He does this on purpose.

    Besides, the ADT concept is actually the single one that discriminates procedural languages from OO ones. The gap is not so wide as you seem to believe.

    I haven't started from his thoughts because he's an authority: I just like his approach and you, as a mathematician, should like it as well :-).

    Anyone who dares to create an OO language like Eiffel deserves to be taken seriously, I think.



  23. Cristina,

    Well, I wasn't upset, except if by upset you mean being critical :)

    Otherwise, yes, you're right, he built a wonderful language, an object-oriented framework for software engineering.
    Procedural languages are indeed not far from procedural ones and it is my opinion that OO languages should be classified within the 3rd generation together with the procedural ones.

    But he also gave a long , fuzzy and irrelevant definition of component.
    If you think we should stay within Meyer's definition I think it's ok, it is even very inclusive.

    Everything is a component then.

    So you failed again on my quality criteria for the component definition, this time on Meyer's hand :)

  24. Cristina,

    Sorry if I seemed not to take Meyer seriously.

    But let's go back to mathematics and have a little reductio ad absurdum reasoning.

    Let's assume that the specific qualities you mentioned (adapted from Meyer's) are indeed differenciating components from non-components.
    Let's go then and see which software artifacts do NOT classify as components.

    I'll quote you and add the NOT operator together with the OR (of course reversing the AND condition).

    So in order for a software arifcat to clearly fail to be a component it has to either:

    - NOT
     . *be a module* satisfying a number of well-defined modularity conditions;
       That means except for excutables, being a bad piece of software. Who writes software these days without using modules ?
    - NOT
     . *be weakly coupled* with other modules;
         That means being a badly designed and badly written module. While "weakly coupled" is something relatively fuzzy, not being weakly coupled I guess means either directly modifying the other module's data or using the other's module internal interfaces.
    - NOT
     . *be accessed only through a public interface* which hides its implementation from clients.
      Again , let aside this is being generally forbidden and enforced in modern programming languages with a few exceptions (C++ classes and Java package visibility functions where we usually put "friends" in the same package), that means bad programming.

    So it follows from our assertion that every piece of software that does not qualify as a component, is obviously a bad piece of software.

    I guess we could do it this way but it wouldn't be quite right.


  25. Hi everybody.

    No I have not been sleeping. We have had some holidays in Germany and I used them
    to fly gliders all day long, which has nothing to do with components but is even
    more interesting :-)

    Jokes aside, I have read all the postings and I have some comments on them, although
    I still do not have a definition of a Component.

    First of all, we have to accept that different people use the term component
    to mean different things. This is unfortunate, but it is a fact. So we will
    never succeed in defining the term for all its uses. This simply cannot work.
    But we can of course define (or as mentioned before, describe) what we
    mean by a component. I already mentioned, that the book contains a section
    that differentiates our component from other components. Namely, it describes
    that components in our sense are not
    - GUI components (like ActiveX, VBX, OCX, etc).
    - Business Components (like SAP modules, etc).

    So, let's describe it again.

    A Component needs a container to run in. The container takes care of some
    aspects of a component's functionality that the programmer does not want to care
    of by programming. This is the separation of technical and functional concerns.
    He only specifies some of these technical requirements ( like tx, security, etc)
    in annotations.

    An operating system in the case of stdio.h is not a container for several reasons,
    although it has some of the same properties.
    - first, it is an operating system. Most people understand that an OS is not
      a component container (unless one is integrated, as in MS Windows 2000).
    - second, you cannot specify anything like annotations when you depoy a stdio.h

    A component also is not an object, because it is larger grained. Objects
    have a set of properties such as polymorphism, inheritance, etc. Components
    don't. Components are not OO. Components can be made up of objects internally. But
    it is ok to implement them in a non-OO way. So, Components simply act on another
    level of abstraction that objects. And by the way, there is no such things
    as annotations for objects.

    IDEs. Yes, the GUI (and some non-visible) components like VBX and its children
    focus on design time, design state and IDE integration. It is ok for them to do
    so. But as I pointed out before, this is another kind of component which should
    actually use another term (of course, we can also agree on using another term
    for the kind of component we try to define here.)

    Components and Frameworks. I have once written a whole article on that topic.
    (Unfortunately it's german). I think there are clear differences between
    components and frameworks, and they can also benefit from each other.
    - a component is complete (together with its annotations) and can be used.
      A framework, by definition, is incomplete, and has to be instantiated to be
      used (by an end user, as "using" a framework actually means instantiating).
    - a component can be created by instantiating a framework. Or seen from a
      different angle: Internally, a component can be built by using a framework.
    - Component architectures (like EJB) usually use f/w technology in order to
      realize the component architecture, as someone pointed out before.

    So, as a concluding remark. I think it is not useful to try to define
    what a component is in general, because there are too many different uses of the
    term. And if we have a common understanding of what a component is *in the context
    of the book* (or any other context, for that matter) I think we are fine.

    And yes, I will expand the section in the book which describes this fact.

  26. Markus,

    A short and useless comment: I think your post finally hits the nail on its head.
  27. I agree (with your statement about Markus comment, not that yours was useless.) :-)
  28. Hi Markus, As much as you have my sympathy, I'll tell you where you think you commited some gross inaccuracies.

    "So we will never succeed in defining the term for all its uses. "
    Well, you're wrong, in the worst case I'll have a definition saying a componeti is either "this" or what Markus says it is.

    " I already mentioned, that the book contains a section that differentiates our component from other components." So, you could define your class of components as a subclass of components in general.

    "So, let's describe it again. "
    You could as well define them. While you say you can't give a definition for all components pecause many people give different meanings, you should at least be able to give a definition of "your" components, otherwise you're not talking CS you're talking empyric observations.

    "A component also is not an object, because it is larger grained. Objects have a set of properties such as polymorphism, inheritance, etc. Components don't. Components are not OO. "

    Totally false. Components are NOT NECESSARILY OO.
    Usually they are OO.
    I can give you plenty of examples where components do have polymorphism inheritance and other OO properties.

    "The container takes care of some aspects of a component's functionality that the programmer does not want to care of by programming."

    This property is essentially not specific to components.
    it's called Aspect Oriented Programming as you know already and while AOP and CBD do intersect, none is included in the other.

    "So, Components simply act on another level of abstraction that objects. "
    That's poetry, it basically says nothing.
    If you bother, please explain this "other level of abstraction".

    "But as I pointed out before, this is another kind of component which should actually use another term "
    You should use another term if we care about such issue as ethics when we're talking about Computer Science.
    So let me remind you that :
     - components such as VBX and VCL and ActiveX has apeared long before EJBs and stuff like that.
       They used the term component and they made the idea of Component Based Development a successful reality
     - still they are technically more advanced then EJBs even if EJBs apeared after them and could have learnt something in the meantime.
       They don't have design flaws in their spec as EJBs does, they make the application developer much more productive then EJBs , especially because they focus on design time.

    So while you may sound condescendent towards the old components, you might be able to realize that "your" components have still a long way to go before they reach the technical level of the components.

    So it's totally absurd from your part to pretend that components like VBX and Delphi "should actually use another term".

    About components and frameworks, you basically say that frameworks are incomplete (because they have to be instantiated (in the source code I think)) while components are complete together with their annotations.
    Well, components are also incomplete sometimes, they have to be connected with other components in order for them to be complete, while all by themselves they are incomplete.
    But you might have a point about instantiation.

    In the end the only thing I kept from your component theory is that a component has to have ANNOTATION.
    Well, annotation as you defined there is the involution from the design time state.
    At a limit you can regard annotations as a design time state.
    However annotations as some propeties put in a file is not something that differentiate component from frameworks, frameworks also do have annotations in your sense, even a C library have this type of annotations, maybe not <stdio.h> but others have plenty.

    And just because Sun so choose to diregard this powerful concept of design time state, that doesn't mean that EJBs should not have IDE interactions, design time state as Cristina pointed before.

    It is just that the EJB spec is awfully imatture in this respect (CBD) also as it is in other aspects.

    This doesn't grant you to say that the former category of components shoudl actually use another term, and neither it grants you to draw general conclusions on Component based Development based on a paricularly immature technology.

  29. Ooops, missed the "should use another term" comment when I read the first post.

    I have to agree with Costin here. You can't suggest to those that used the name first to change it because you want to use it to define something else!



  30. Ok,

    So if we are not able to agree on specific difference which should give us the definition I think we might be able to find the most specific enclosing class.

    It should be easier to agree on, and we can go from there, at least by enumerating what different people think of components, giving each a definition and applying the OR operator.
    Of course we should avoid having too many different notions because some may be not legitimate use of the term component.

    So my thinking goes that in order to find the most specific enclosing type it would be useful to enumerate the relatives and figure out from there.

    So me thinks that the notions related to components but clearly different from components are: OO frameworks, procedural lbraries (non-OO framewroks I could say) and that's about as close as you can get.

    Therefore the most specific enclosing class for components is the class of software artifacts that do not constitute the end product of software development, but contribute to many end product by various assembly techniques that facilitate reuse (the same software artifact contributes to several end product).

    Though my english skills are not that good to provide a good formal definition I think we could settle for what I described as the most specific enclosing class.

    It is obvious that it is an enclosing class, the only problem is if we could find something more specific than that.

    I thought of various classes of software artifacts but I couldn't find something more specific and still a proper superset of components class, so I ask for your contribution in this regard.

    Also I must same there is no formal generic name that I know of, for what I defined but we can aslo manage without a name as long as we have a clear definition.

    What do you think ?

  31. Ok folks,

    I gave it a try. I have added a section in the book's
    introduction, which aims at differentiating our use of
    "Component" from others.
    What do you think? It's available from

  32. I too have been thinking for quite some time that EJB's are *not* components in any useful/modern definition of the world. There are signs they're getting there, but not quite. one could, for instance, hack a "property panel" of sort onto deployment environment variables, but that leaves no way of programmatically exposing what kind of properties are supported except through user documentation.

    Also, I think the forthcoming XML-based persistence for JavaBeans (not EJB) will be a big (and long overdue) step forward in bringing Java components up to where OCX's, Delphi, and even NeXTStep has been for quite a while.

    For some reason there seems to be a big tendency to code-generate things in the Java community, i.e. to love the get/set methods on JavaBeans, or to code-generate all these interceptors for EJB, etc. All this compile-time type checking may look like a good idea at first, but I think it gets out of hand.

    On another note, Anyone ever read Oliver Sims' original book on "business objects" (which were effectively supposed to be server-side components)? It's quite enlightening as to what would be required to compose a distributed system out of components. He doesn't concentrate on the IDE / development aspects, he concentrates more on the practical aspects of the underlying component container.

    As an example, to allow for platform & language interoperability, Sims felt that strong interfaces & early binding wouldn't work, primarily due to complexity of linking + code generation required to do traditional cross-language RPC with some sort of IDL. So a "semantic data stream" was his solution - pass the type info as metadata along with the data during the call... which (interestingly) is the same model that these XML web services seem to be approaching.
  33. Stu,

    "All this compile-time type checking may look like a good idea at first, but I think it gets out of hand. "
    You're longing for your old Smalltalk days, aren't you ?

    Well, not that I necessarily disagree with you, but I think you also agree that distributed or not , distributed by the way of IDL strong typing or XML documents (hey, CORBA doesn't force you into strong typing either), the distribution mechanism is orthogonal to the component definition.

    I think though you might be dreaming a little about semantic meta-information passed along in the invocation context.
    In order to have that we'll have to go back to the long forgotten by the industry, AI research.
    For components to collaborate we still need developers to collaborate today, with or without strong typing.
    Loose typeing as in Smalltalk is only a grammar illusion, or a convenient way of writing code, we need a little bit more than that, and somehow our industry has forgotten to be visionary or revolutionary along the way.
  34. Markus,

    "Module as Components"

    This is a gross terminology abuse.
    Why were they called modules/libraries/units/packages but they were not called components ?
    Please let us know who with authority within structured programming domain, called modules components.
    Let's take your example, DLL.
    DLL stands for Dynamic Linked Library not Dinamic Linked Component.
    Please note that Microsoft calls more specific things as components and ActiveX as a Component (according to its author)is physically distributed inside a specific type of DLL.
    This should be enough to raise you a flag that you cannot call DLLs components.

    "GUI Components"

    I guess your bias shows here in using the past tense and the easyness on how you equate some things.
    So, IDEs includes GUI builders but you can't say "GUI Builder (IDE)".
    "GUI Components have a interface as any other software module, they include an (usually optional) additional interface for interaction with the IDE, but you state:
    "Note, that the interface was not used in this case to be able to change the implementation, rather it specified a protocol how IDEs could use the control to let the programmer &#8220;point-and-click&#8221; applications: they provided readymade functionality for assembling GUIs."
    Is this an opinion or an observation or you really believe what you are saying, or you got your phrase wrong ?
    So, "GUI Components" abdicated from the principles of structured programming in order to focus on point-and-click for assembling GUI.
    But the biggest flaw here is to call them "GUI Components".
    You can find ActiveX for SMTP/IMAP/POP3 for instance that never show their face to the user, the same with Delphi , JavaBeans, and VB components.
    More, the definition for each of them does not mandate them to be drawn on screen.
    Only a subclass of those are visual components.
    You also can use Delhi components for instance to build totally non UI applications.

    After these two failures you got them right in what you believe to be distributed components.

    I guess it was better if you only focused on describing what you call components, and let aside your opinions about other types .

  35. Costin,

    > "Module as Components"
    > This is a gross terminology abuse.
    To make clear one thing. I do not say that modules
    are components - I just say that the word Component
    is *used* sometimes to mean DLLs, etc.

    > Please note that Microsoft calls more specific things as > components and ActiveX as a Component (according to its
    > author)is physically distributed inside a specific type
    > of DLL.
    I know that. See below. But people do other things
    than Microsoft proposes. For example, they call
    DLLs components.

    "GUI Components"

    > But the biggest flaw here is to call them "GUI
    > Components".
    > You can find ActiveX for SMTP/IMAP/POP3 for instance that > never show their face to the user, the same with Delphi , > JavaBeans, and VB components.
    I programmed with Delphi and VB, so I know that.
    But they originated from visual Components - that's probably
    the reason why Borland calls its VCL VCL.

    > I guess it was better if you only focused on describing
    > what you call components, and let aside your opinions
    > other types .

    Costin, I feel your tone's getting a bit aggressive :-(

  36. Costin, I feel your tone's getting a bit aggressive :-(

    I am critical , some people think I am agressive in the same way other people are suposedly saying DLLs are components :-)

    Even if you didn't say DLLs were components, it still is a terminology abuse and if you put it in your book without any caution will be a terminology abuse in your book, the initial "authors" will no longer be responsible.
    Common, Markus, maybe some people said DLLS are components in the same way I could comment about Pete Sampras that he doesn't put the right effect on the ball :)

    Do you put this only to justify you not to give a definition ( even large or vague ) of the component ?

    "But they originated from visual Components - that's probably the reason why Borland calls its VCL VCL."
    Ok, let aside that Delhpi had non-visual components right from version one, than why don't you call them visual then ?
    And from version one you could read in the help that there were two types of components: visual and non-visual.
    Visual Component Library is just a nice name, but is anyway better than "GUI Components Library".
    You could still get away with naming them "GUI Components", as loing as you don't wright the other false things about them.

    I have the right to be critical as your friend, as long as you don't wright an unbiased presentation of facts with regards to the history of component based development.

  37. Hi Markus,

    it seems this entire thread leads to a single question: does it make sense to look for a context-independent definition of the term "component"? Probably not.

    Such a context is a "component architecture". Things now begin to make sense. The component game is like a puzzle, so to say.

    While searching for a more precise definition of component architecture, I came across the Common Component Architecture (CCA) project:

    There's also an implementation of the CCA spec elsewhere:

    You're probably aware of both initiatives. If you're not, however, maybe you should give it a try. I haven't read enough to tell you whether the CCA spec includes distributed components, but the ideas involved are interesting anyway.

    At least, they may help you avoid religious wars when trying to define something :-).

    From the CCA glossary:

    . A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. Multiple components may be composed to build other components.

    . A component architecture is a system defining the rules of linking components together.

    . A framework is a specific implementation of a component architecture.

    Hope this helps,


  38. Hi Cris,

    Regardless of what it may look to you as "religious wars", you just gave an example of a niche thing.
    There they say "architecture for high performance components", so EJBs are excluded from the start :)

    No, of course I wasn't aware of this particular effort (who can be ?).

    But before I'll have time to digest the thing (if ever, but can you promise we don't waste time studying the thing), I'll observe that is in the area of high performance parallel computing, thus not quite the domain we discuss here.
    But they seem to be at version 0.5 and their definition for component is quite far from a precise thing
    "Technically, components are the basic units of software that are composed together to form applications."
    This is my quote.

    As to what you cited is another example for how people tend to take ownership of terminology.

    ". A framework is a specific implementation of a component architecture. "
    Well, I developed framewroks totally unaware that I was implementing component arcghitecture.

    ". A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities."
    As unclear as it gets, not to mention it is indefinitely recursive so useless.

    No, I can't agree that component is anyway we choose to partition software efforts, and while the CCA effort may be vaulable within its own domain, the definitions can hardly be generalized or have an overall value.

    And how do we solve the chicken and egg problem, Cris ?

    We can't define components but we try to define component architectures ?
    Doesn't make much sense to me

  39. Hi Costin,

    I'm just suggesting that the definition of "component", whatever it may be, is probably context-dependent. You seem to acknowledge that when you notice the CCA project is being developed in the context of high performance computing.

    Of course I've noticed that as well... Still, the idea of a component architecture that tries to bridge the gap among different component models is interesting in itself.

    Such an architecture should be, at least, more generic than the specific ones it tries to integrate. If you accept that, then the definitions will be more generic, too. I believe Markus would benefit from taking a look at a component model that aims to be generic from ground zero.



  40. Component definition[ Go to top ]

    Hi Chris

    Yes, if definition were as generic as we quoted then we'll go back to Alan Turing and have the perfect definition of architecture :)

    Genericity is not necessary a quality in all situations, so generally we don't want a concept to be extended to its conceptual superclass so we don't want genericity at all costs.

    But viewing that even Stu, one of the most stubboorn defenders of Enterprise Java Beans seem to acknowledge they are not necessary components, only they have the potential to be, strengthen my belief that I am not totally wrong in trying to give a definition.

    Meanwhile nobody seemed to argue about the most specific enclosing task which might look that I was right, or nobody cared enough to argue a different opinion about that.
    So I'll take for granted for now that I specified correctly the encolsing clas, so now I'll try to go again to the definition.

    First of all I want to argue that the nature of the component has little to do with how a component is implememnted, so the definition should not care at all of the component writer, but at the component client.

    So we don't care how the component is produced but how it is used, more precisely how it is reused over and over again.

    And here we have the difference between components and his cousins such as frameworks, libraries, modules and so on.

    Components focus on a qualitatively different (not better or worse but different ) aspect of software reuse.

    And what should this qualitatively different aspect be ?

    The other reusable software artifacts are reusable by code, you code against their interfaces, which is good and flexible, but sometimes is cumbersome and repetitive.

    So components are different at design time, when you're building the application.
    At run-time there's no difference between how a components behaviour and framework objects behaviour for instance.
    Even if we accept EJBs as components on the grounds that they plug into a container that offer transparent services such as security and transactions, we should not that this behaviour is not different then if I plugged a class of mine into the extension point of a class framework.

    So clearly the definition should focus on design time.

    At a minimum, the component should be configurable at design time, that is various aspects of run-time behaviour should be specified at design time without writing lengthy constructor calls or writing tens of setXXX().
    Here EJBs seem to qualify.

    But Stu was right here.
    What is the fundamental difference between specifying properties in a file and calling setXXX in the source code ?
    There could be only one, and that is we shoud receive at least some feedback and ideally some interaction from the component we configure about what we specify at design time, otherwise it is to expensive to find out at run time that our configuration was wrong, and we wouldn't have a qualitatively different aspect of reuse.
    By providing design-time interaction a component gives us a qualitatively better aspec of reuse, it facilitates reuse.
    And this gives us the specific difference from the enclosing class of software artifacts.

    At a minimum, the design time interaction could be something like a drop down list in a property editor from where we could choose valid parameters, or the component could signal to us that the configurastion is not valid.

    But more advanced components provide a configuration process where they help their user to configure them correctly and even preview the run time behaviour in order to make sure that the configuration was the thing that he wanted .

    This clearly facilitate reuse because considering the more complicate and expensive software stacks at runtime it is far more preferrable to get our feedback at design time, and to be helped to get things wright.

    With a framework you can't do that, you could code against the interfacse, even edit some properties files then test it a run time and pray it works.
    This can be quite expensive, and we all know how expensive is the code, compile, generate, run catch the error cycle with app servers.
    More the error can show its nature only under certain concurrent conditions that are not easy to be generated by the developer.

    So I rest my case and tentatively give a definition:

    A component is a reusable software artifact that facilitates reuse by providing some kind of interaction to its client developer at design time, in order to help the developer configure and/or code it so that the developer can achieve the desired behaviour at run time.
    The component inherit all the other properties from its most specific enclosing class: it is modular, it has a clearly defined interface and so forth, see above.

    EJBs and other "components" are not excluded by this definition, they don't qualify by their specification but they can qualify right now if they're used in certain IDEs that provide adapters for desgin time state as Cristina and Stu pointed out.
    However these adapters have their incoveniences and the right solution would be to define the design time state/interaction in their respective specification.

    Meanwhile the definition has a qualitativelky different aspect that separate compoents from its enclosing class, and the other orthogonal; aspects such as distribution transactionalbehaviour and so on can be used to differentiate subclasses in the component category.

    What do you think ?

  41. Component definition[ Go to top ]


    I've been telling you what I think once and again. Problem is, you just won't listen to a software architect (even if she's a Java programmer as well :-)).

    I'll try again anyway... I think it would be nice if we could discriminate components from their enclosing class, as you say, by a single feature: design-time support. I acknowledge it can be seen as the hallmark of a well-designed component architecture (yes, since design-time support only makes sense when you have a well-defined context). A component is still a component, however, even if it isn't capable, by design, of offering design-time support to the component assembler.

    Let's get back to the example I was talking about yesterday. The CCA does include design-time support in its spec. It's called Composition API:

    "A Composition API allows the programmer to link components into multi-component applications and save those compositions. Such a mechanism could be provided for example by a GUI or a scripting language, and need not be standardized in a CCA."

    As you see, they are suggesting components can be assembled by means of a GUI or some programmatic tool. Besides, as the implementation of such an API doesn't have to fit a standard, it's definitely not seen as a fundamental quality of a component.

    In my opinion, design-time support is an overconstraining requirement, Costin. I hope we'll see the day where it will be taken for granted as part of any component architecture. The lack of such a support can't be used, however, as a category discriminator.

    Interestingly, design-time support is not a property of a component by itself, but of a component *architecture* :-).



  42. Component definition[ Go to top ]

    So your example provides by its "architecture" design time support. Of course there's no need to standardize the tool as long as the API for design time interaction exists. It is also the case of JavaBeans.

    The context you want so bad just cannot be specified because contexts are so different, however I can specify you the meta-context : you develop something (an application or even just a reusable software artifact) and you want to yake advantage of reusable software artifacts.

    It is as simple as that. When do those reusable software artifacts qualify as components ?

    You say that design time support is over constraining, and you hope to see the day that is taken for granted.
    Why ? Just because some things are proclaimed components and they wouldn't qualify under this constraint is not a good argument.

    You haven't been able to provide an alternative definition that would differentiate components from frameworks, libraries and other reusable parts.
    First you have to do that, you cannot just define by enumerating : JavaBeans are components, EJBs are components, COM/DCOM/COM+/.NET objects are components, etc.

    At least you'll have to agree that at run time component's behaviour is no different than the behaviour of other software parts.

    And we'll go from there.
    Come with an alternative definition, and I gave you the criteria, and let's discuss that.

    For me , after long thinking I am more and more convinced that design time support is the criteria.

    It does not necessarily have to be wizards or property editors, or fancy IDEs like Delphi, but it has to be something at design time, and has to be something at design time for the client developer who uses the components, as long as components can be written in any way the component writers see fit.

    And what differentiate at design time (that includes also traditional editing/compiling/linking) ?
    I proposed a criteria, let me see if you can find something else.


    "hope we'll see the day where it will be taken for granted as part of any component architecture"

    My project manager says that once you introduced a feature and raised the bar you cannot take it back in subsequent releases, because qa will tell you that you introduced regression problem, and no one from upper management will want to downgrade.

    Now everybody here admits that Delphi and VB raised the standard, and they did that long time ago when they were running on 16 bit Win31.
    Is it reasonable for us, already in the 3rd millenium to lower the standards ?
    My thinking is NO WAY, the standard has to stay there.
  43. Component definition[ Go to top ]


    Firstly, the distribution model is orthogonal to component definition in some ways, but the method of distribution has profound influences on how a component contract is defined. If you're using an RPC protocol, for instance, you're already making some assumptions.. otherwise yes, there are definitely orthogonal considerations to make.

    "I think though you might be dreaming a little about semantic meta-information passed along in the invocation context.
    In order to have that we'll have to go back to the long forgotten by the industry, AI research. "

    Well, that's taking it to its logical conclusion, but in the interim I'm not even talking about that. Passing along semantics with an invocation has a practical consideration: I'm no longer bound to an object-model-specific invocation.

    Most distribution models in the past have been tied to an object model.. most dispatch systems were implemented "on top of" procedure calls... whereas something like a meta-data based approach eliminates parameter position binding for one. One merely has a list of tags to match up to. It's a small difference, but it's a start to start to "loosen up" these definitions to allow for more dynamic collaborations between incompatible programming models.
  44. Component definition[ Go to top ]

    Coming from an old-timers perspective (Jeez, I'm only 35), a component is a module which may be dynamically composed into a working system. Obviously that depends upon the power of the environment.

    As such EJB's are components of an EJB container. If one uses a more functional container e.g. Sybase EAServer (ex Jaguar CTS) then any number of language object modules may be dynamically composed, even mixed, to produce working systems.
  45. Costin,

    You are asking for a formal definition of software components but fail to provide one yourself.

    The main point you seem to make is that defining property for a component is its amenability to being USED by programming tools such as IDEs. And by IDEs I think you mean visual IDEs.

    Then let me ask you this:
    1. If I take <stdio.h> and its coresponding .obj file and
    drag and drop them on a canvas then from a property sheet I select printf() and when a dialog pops up I write in a text box "Hello world!" then click "Ok" and then "Run", would then the stdio.h and obj file qualify as a component?
    While this example shows quite an impractical form of programming it's nevertheless possible.

    2. Do COM+ transactional components qualify as components ?
    They are not buildable visually (neither are most VBX, OCX,
    VCL components, BTW!), they do not have any design mode and
    it's not practical to use them in a visual IDE.

    I think it's an exercise of futility to try to be mathematical about certain concepts that haven't quite a precise meaning.

    For me, components rhymes mostly with binary, object *oriented*, reusability a.s.o. The list can be really long, it depends a lot on context.

    However, I must agree, it is common sense to start a book about a specific type of software components by describing (not necessarly *defining*) what are and what you mean by components.

    Best regards,

  46. Cristi,

    Yes I agree, you might not be able to define them precisely after all, but you have to at least DIFERENTIATE them from other software artifacts.
    Yes, we might end up with ANSI C library being defined as component and it wouldn't be quite right, or would it ?

    Otherwise it is only terminology abuse, in order to take advantage of the hype (Component Based Development).

    But the example you gave isn't really a contra-argument because you need to write an adapter to printf(...), C headers and object modules are not per se usable in IDEs and don't havea design time mode per se, while if you may observe for VCL, ActiveX, JavaBeans there is a design time mode specified in their contracts.

    Ok, if COM+ doesn't qualify as component by my definition so what, neither EJB does.
    If I'm not mistaken the main usage of COM+ objects is programatically by code, and also the most efficient qway of building them is by using ATL, which proves they are definitely OO frameworks.

    Do you agree at least that there has to be a clear difference between frameworks and components?

    So you rhymes are not quite precise, are they ?
    So you can abuse this notion, and it's certainly a good cause to try to avoid that.

    Let me be more clear, I wasn't saying my definition is THE definition, but I wanted to provoke a discussion where we may come up with something close to a definition.

  47. I don't actually agree that the definition of component has anything to do with OO. We already discussed that some artifacts of VB are components and we know that's not object orientated.


  48. I made a terrible mistalke in the previous post.

    How a component writer builds a component should have nothing to do with the definition of a component.
    So please disregard that.

  49. And one other thing we miss in this discussion is references to what others discussed about components.

    So primarily for definition there are nine gathered at

    For a broader picture you can look at

    Also, has a broad collection of articles on components.

    Luckily or unluckily, the problem of defining the component concept is not yet settled so we might have some work to do here.

  50. Costin >

    Frameworks provide reusable design, components provide reusable functionality.

    So yes, I think the EJB API is a framework (it consists mostly of interfaces), but a framework used to build *server-side* components that by themselves are later used (and hopefully reused) to build *server-side* applications.

    Yes, there are differences between client-side
    type components (ActiveX, VCL, JavaBeans) and the newer server-side ones (COM+, EJB). But they all qualify as components, IMO.

    Note: by client-side I don't mean visual. I know there are components like TServerSocket in VCL but no one in it's right mind would use it for some serious server side app.
    Oh,wait ... I did! :)

    Tony >

    I emphasized *orientation* in object orientation because
    the component models we mostly work with support some OO
    concepts, like encapsulation but are not fully objectual.
    (many lack inheritance, like EJB and COM do).

    There is a strong relation between OO and the components

    Most people I think see components like binary objects. You could notice there is not much difference between a normal Java class and a common JavaBean.

    Best regards,
  51. Hi Cristi

    >Frameworks provide reusable design, components provide reusable functionality.

    Well, as a good fellow Romanian, you must have studied Mathematics together with, and even more than, Computer Science but you certainly don't like your definition to be precise :)

    More, if you want me to understand something from the above I understand it as a poetic description.

    For me STL, or Collection API, or any decent framework give me reusable functionality in the first place.

    Yes, there are differences between client-side
    type components (ActiveX, VCL, JavaBeans) and the newer server-side ones (COM+, EJB). But they all qualify as components, IMO.

    Yes, I understood that and respect you opinion although I may think differently.

    But the point and the challenge was to share with us why you think they are components.


    And non-visual components in Delhpi can be used in very serious application without any sanity problems.
    Just think of TQuery family, that you can't do without very easily.

  52. Quote from Markus:

    >Waiting for your reply :-)

    I guess you must have been sleeping this weekend :-)

  53. Quote from Markus:

    >Waiting for your reply :-)

    I guess you must have been sleeping this weekend :-)


    Or alternatively, unlike both of us he has better things to do with his weekend. :-) (I am also guilty of spending weekend time reading the site. :-))