[OT] What's in a component?

["Fernandez Martinez, Alejandro" <a....@ibermatica.com>]

Hi folks!

I've followed (as best I could) the discussions here and on general@jakarta,
about making components reusable and sharing them. However, an old doubt of
mine arises now and again: what is a component? Or, if you prefer an
operative definition, what are the necessary steps to make a bunch of code
into a component? Sun's Java site, for example, talks all the time about
them, without defining the term; and even when they are a standard member of
UML diagrams, I've never seen the concept discussed.

I will now expose my musings on the subject. They are just a gross
approximation but, lacking a more accurate description, it can serve as a
starting point.

I think that the notion of 'component' must be closely related to what a
'framework' is. Only inside a framework can you define what entities can
reside inside it, and call them 'components'. Also, when you have a bunch of
'components', you can call that a 'framework'.

But the term hints at 'independence' too, as if they could live on their own
(which is seldom the case). Even worse when 'reusable' is added. Any piece
of code needs a basic set of services, usually the same, that must be
provided somehow -- if the framework does not, or there is no framework,
then the user should.

Now, going to the operative side of the question: what problems do arise
when trying to make components really independent? E.g., take them from
their craddle framework and put them in Commons. They are quite often the
same: build, discovery, log, communication, error management and
configuration. You can surely add a few more of your own.

It's probably not the time to enter a point-by-point discussion, for those
that are still reading this far. As a general remark, some of these issues
are no problem in Jakarta land: the build tool (ant) is standardized, and
error management only lacks a firm criteria for checked exceptions. Others
are more tricky: there's a logging component (log4j), but some people have
decided to go in other directions, and a common interface (logkit) has been
built. Still others are a complete mess, such as component discovery and
configuration.

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.

Un saludo,

Alex Fernández.

Re: [OT] What's in a component?

[robert burrell donkin <ro...@mac.com>]

i (personally) started using the term 'component' rather than subproject 
for the stuff in the commons since "commons sub project" is confusing 
because jakarta is an apache project and jakarta-commons is a jakarta sub 
project. the commons charter talks about packages but using this word is 
also confusing (since some components contain code in more than one java 
package).

you make some interesting points but i don't have any answers...

- robert


On Thursday, January 10, 2002, at 12:59 PM, Fernandez Martinez, Alejandro 
wrote:

> Hi folks!
>
> I've followed (as best I could) the discussions here and on 
> general@jakarta,
> about making components reusable and sharing them. However, an old doubt 
> of
> mine arises now and again: what is a component? Or, if you prefer an
> operative definition, what are the necessary steps to make a bunch of code
> into a component? Sun's Java site, for example, talks all the time about
> them, without defining the term; and even when they are a standard member 
> of
> UML diagrams, I've never seen the concept discussed.
>
> I will now expose my musings on the subject. They are just a gross
> approximation but, lacking a more accurate description, it can serve as a
> starting point.
>
> I think that the notion of 'component' must be closely related to what a
> 'framework' is. Only inside a framework can you define what entities can
> reside inside it, and call them 'components'. Also, when you have a bunch 
> of
> 'components', you can call that a 'framework'.
>
> But the term hints at 'independence' too, as if they could live on their 
> own
> (which is seldom the case). Even worse when 'reusable' is added. Any piece
> of code needs a basic set of services, usually the same, that must be
> provided somehow -- if the framework does not, or there is no framework,
> then the user should.
>
> Now, going to the operative side of the question: what problems do arise
> when trying to make components really independent? E.g., take them from
> their craddle framework and put them in Commons. They are quite often the
> same: build, discovery, log, communication, error management and
> configuration. You can surely add a few more of your own.
>
> It's probably not the time to enter a point-by-point discussion, for those
> that are still reading this far. As a general remark, some of these issues
> are no problem in Jakarta land: the build tool (ant) is standardized, and
> error management only lacks a firm criteria for checked exceptions. Others
> are more tricky: there's a logging component (log4j), but some people have
> decided to go in other directions, and a common interface (logkit) has 
> been
> built. Still others are a complete mess, such as component discovery and
> configuration.
>
> 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.
>
> Un saludo,
>
> Alex Fernández.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [OT] What's in a component?

[Ringo De Smet <ri...@users.sourceforge.net>]

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!

Ringo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>