Episode 87: Software Components

Filed in Episodes by on February 21, 2008 10 Comments

Recording Venue:
Guest(s):
Host(s): Michael Markus
In this episode, Michael and Markus talk about software components. We first looked at a couple of attempts at defining what a component is. We then provided our own definition that will be used in the rest of the episode. We then looked at the promises of component-based development: why are components useful?

We then discussed some of the typical metadata components should specify to make them useful. We discussed to some extent typical variations in component models. The next topic was the separation of concerns between the component functionality and functionality provided by the component’s execution environment (aka. container).
We then compared components with other (more or less) related technologies such as OO and SOA.

We concluded the episode with the notion of architecture as language, where you use a formal DSL to describe a system’s architecture. Components are the basic building block for this approach.

Links:

Tags: , , ,

Comments (10)

Trackback URL | Comments RSS Feed

  1. AlexMtl says:

    Hi Markus,

    I sent you an email about that,

    Thanks!
    Alex

  2. ChristianDietrich says:

    Hello SE-Radio,

    first i want to say thank you for the great job you do on the Podcast. Software Components is a very interesting topic for me. What i have missed in your listing of technologies was OSGi. In my opinion it is a easy way to extend the Java Class and Jar Stuff with just a few additional means to get a good and useful java based component model. And as you look at e.g. the new Application servers, they are built on top of this component model.

  3. Markus says:

    Hi Christian,

    you are right, I should have mentioned OSGi in this episode. I simply forgot it :-)
    Here’s more on it:

  4. PeterM says:

    Hi SE-Radio

    This is an excellent episode. It has given me a better understanding of using components as a high level absraction to break a system down.

    I have started using the principles this week and it has really helped clean our system structure.

    I have the sense that Michael has more to say on this topic and I would be interested to hear more of his thoughts.

    Thanks for the effort you put in.

    Regards,
    Peter

  5. Douglas M dos Santos says:

    Hello SERadio !
    Since I found these website , I just cant stop listening it in backgroung while working.
    Best regards,
    Douglas from Brazil

  6. Michael says:

    Hi Peter

    Thanks for your comment and your question about my further opinions. To respond to this: Markus and I have for large parts the same opinions about software components and how to use them. It is just that I mostly used the concept of component more pragmatic, less formal, but that is because my projects where not using any model-based stuff. So to me it was important to define for my team(s) how to decompose the overall architecture in something like subsystems and components. I defined the granularity of a subsystem and a component on a per project basis. What always stayed the same was the explicit documentation and enforcement of (architectural) dependencies, and using explicit interfaces for this. With the strong focus on enforcing the definition of contracts – decoupling the interface from the implementation – I was able to enforce clean design with minimal dependencies.
    To be honest, in many past projects, I did not call the usage of components with their required and provided interfaces a ‘domain language’ – a architecture language – as recommend in the episode. I mostly enforced the kind of thinking through talking, reviews, guidelines, and sometimes by (middleware) technology, such as CORBA or ICE, which require you to explicitly model your intefaces in some form of IDL. Nevertheless, reflecting about it: today it helps making this kind of thinking more explicit, e.g. as a language, at the beginning of a project.

    Regards,
    Michael

  7. fbouchet says:

    Hi Peter/Markus,

    This episode is really helpful to setup the scene.

    I would have been interested to also get your opinion from both deployment and operation perspectives. If SOA is not new, when it is applied to enterprise applications infrastructure these aspects become really challenging. For example,

    a) deploy a new version of a component (and restaure the original version in case of problem) without interrupting the other components using it.

    b) keep control of the performance of a component and its dependencies when its number of clients increases rapidely (it is difficult to predict in advance the usage model of the component).

    c) identify the cause of a SLA alert when the component raising it depends upon other components and the ressources they use (OS, network, DB, …).

    People in charge of these activities are going to exposed to much more complexities (smaller manageable elements with much more dependencies). This complexity will have an impact on ITIL processes (release management, change management, …) that most large companies are currently using.

    When a software vendor takes the responsability to bundle components, it usually provide an appropriate set of tools. When components provided by different vendors have to be re integrated, the story is different. Tools are usually complex and expensive to put in place and maintain.

    Thanks for the quality of your podcasts.

    Best Regards.
    Frédéric

  8. Markus says:

    > I would have been interested to also get your opinion from both deployment and operation perspectives.

    right. These are additional topics we didn’t really cover.

    > If SOA is not new, when it is applied to enterprise applications infrastructure these aspects
    > become really challenging.

    I agree absolutely.

    > a) deploy a new version of a component (and restaure the original version in case of problem)
    > without interrupting the other components using it.

    right. An important precondition is to be able to tell statically whether the system will still
    work. This results in a requirements for “versioning” in the models. I think we talked about
    that briefly. Being able to replace it at runtime is typically something that is done via dynamic
    connectors and a clever lookup service where, for new lookups, the new version is returned.
    Combined with Leasing (see Resource Management Episode), you can make sure that after
    a given period of time all clients talk to the new one.

    > b) keep control of the performance of a component and its dependencies when its number
    > of clients increases rapidely (it is difficult to predict in advance the usage model of the component).

    this is actually relatively easy, because the component (or better: it’s container) can do measurements
    and statistics over usage patterns and the resulting performance. While this does not guarantee
    the performance over time, it can be used to alarm administrators of looming problems. They can
    then deploy additional instances for load balancing.

    > c) identify the cause of a SLA alert when the component raising it depends upon other components
    > and the ressources they use (OS, network, DB, …).

    right. This can become really tricky. I guess the only idea I have here is to have good statistics and
    logging….

    > People in charge of these activities are going to exposed to much more complexities (smaller
    > manageable elements with much more dependencies). This complexity will have an impact on
    > ITIL processes (release management, change management, …) that most large companies are
    > currently using.

    right. For really large installations you’ll need a management tool that really provides an
    overview over what is actually going on.

    > When a software vendor takes the responsability to bundle components, it usually provide an
    > appropriate set of tools. When components provided by different vendors have to be re integrated,
    > the story is different. Tools are usually complex and expensive to put in place and maintain.

    agreed, but: the tools’ lifes are significantly easier the more metadata you have for a component.
    Using the modeling approach outlined in the episode provides this metadata. While this does not
    solve all problems, it is a really useful incremental improvement!

    > Thanks for the quality of your podcasts.

    thank *you* for the really good points you’ve raised in this comment :-)

    Markus

  9. AlexMtl says:

    Hi Markus,

    I have been listening to se radio now for a few months with a great pleasure; the subjects are definitely very interesting, please keep up the good work.

    do you have any further reference for component based development that would deal with theory AND practical problems (versioning, evolution, …) and could help to grasp the subject a bit more (and spreads some wisdom about the common pitfalls)?

    thank you
    Alex

  10. Markus says:

    Hi Alex,

    > I have been listening to se radio now for a few months with
    > a great pleasure; the subjects are definitely very interesting,
    > please keep up the good work.

    thanks :-) We’ll try to keep going :-)

    > do you have any further reference for component based
    > development that would deal with theory AND practical
    > problems (versioning, evolution, …) and could help to
    > grasp the subject a bit more (and spreads some wisdom
    > about the common pitfalls)?

    I have a couple of things that I have written for various
    projects, some of that stuff is publicly available. Send me
    an email, so I can send you the stuff privately.

    Cheers,
    Markus

Leave a Reply

Your email address will not be published. Required fields are marked *


*