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.

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

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

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

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

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

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

> 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

I sent you an email about that,

Thanks!
Alex