commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ringo De Smet <>
Subject Re: [OT] What's in a component?
Date Fri, 11 Jan 2002 19:34:01 GMT
Hello all,

First of all, let me introduce myself since this is my first comment to
something on this mailing list. My name is Ringo De Smet and live in
Belgium. I am 29 years old and have once been a colleague of Paul Hammant
(@see Avalon, @see AltRMI). I have 4 years of Java experience, together with
the daily routine of working the XP way (pair programming, unit testing,
iterative development, etc). I do this for a living. Enough about me...

On 10-01-2002 13:59, Fernandez Martinez, Alejandro wrote:

> I think that at least part of the misunderstandings come from not agreeing
> on what a 'component' is supposed to be inside Commons. I hope someone can
> throw a bit of light into this matter, so that all of us can tell a Commons
> component from a mile off.

Now, concerning the definition of a component...

First of all, we write software to offer a solution to a problem. I'm not
going to talk about an application. With the coming of distributed systems,
I sometimes don't find it clear where one application ends and another
begins. A problem is most of the time clearly defined and as such, you will
end up wit a software product that covers the problem domain.

During development of such a product, the developers cut everything up in
building blocks for the sake of abstraction, maintainability, reusability,
etc. Each of the building blocks provide one or more clearly defined
services. A service is in my perspective the software product that covers a
clear problem (as defined above in the previous paragraph). For example,
Log4J is a software product that covers the specific logging service
problem. Nothing more, nothing less. (Let's assume this if you thing it's
not the case...)

How do components relate to frameworks? I say that a component can be
written either as a class library, as a framework or even both. I call a
class library a collection of class that you can use in your code without
any predefined obligations. You instantiate classes, invoke methods on it
and you get results. Frameworks however are collections of classes that
already have some communication patterns defined within the set of classes.
Sometimes you hear people say the following when talking about a framework:
"Don't call us, we'll call you". An example: the Java Naming and Directory
Interface (JNDI).
1) It is a class library, when you look at it from a user perspective. When
you use JNDI classes in your code, you instantiate the InitialContext, you
do lookup's and you get results. This way, it is your code that calls the
JNDI code.
2) It is a framework. JNDI is an abstraction of a Naming and Directory
Service. As a result, multiple providers can be plugged in at the backend
side of the API. If you want to provide a backend to your own NDS, you write
code, but it must obey to some rules lead out by the core JNDI classes. The
documentation states how you inform the JNDI framework of the availability
of your backend code. It will also document typical call sequence from the
JNDI code to your backend code. "Don't call us, we'll call you!"
3) It is both: 1+2 in one product.

My ยค 0.02!


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message