[RT] Musings about Component Architecture

[Berin Loritsch <bl...@apache.org>]

Nothing in this email is something new, but it will put some thoughts of
mine down on the big component architecture picture.

Components exist for one purpose: to make development easier.  Simplicity is the
bottom line and the holy grail of development life.  We do what is easiest to
do.  Rules and guidelines exist to make our lives easier in the long run.  Those
of us who have used components extensively know how they help you manage the
effects of change in an application.

In the years of developing components, the system (aka container) writers have
picked up a few tricks that simplify many aspects of working with components.
Would life be easier without rules?  Yes and no.  Yes it would be easier to do
what you want to do.  No it would not be easier because others have no rules
so there is no real way to work with others.  The concept of contracts were
the first things introduced to make components work.  The contracts are the
set of agreed upon rules so that two parties (components and containers) can
work together for the mutual benefit of each other.

Later on, as component systems matured, we realized that components needed to
be managed in some way.  Most management concerns can be handled by the
contracts, but sometimes it felt too confining as if the rules were there for
the sake of rules.  As more and more aspects of component requirements became
available, other needs arose.  For example, how can I add certain features to
a set of existing components?  How can I write tools to help make developing
and deploying components easier?

Because there are many concerns, and features that can be dynamically added
to a system in the container, we needed a way to control those features.  For
that reason, the concept of meta-information was introduced to the picture.
Meta information allow tools and containers alike to discover important aspects
of a component without forcing the same set of rules on all components.  Take
Phoenix for example.  It requires all blocks to be singletons, it is a confining
rule.  Now contrast that with Merlin, Fortress, and ECM.  They allow the
component developer to tell the container how the component was designed to be
used.  The container then can adapt to the needs of the component as long as
it knows what those needs are.

Without even realizing it, many containers either assumed a certain set of
meta information about a component (like Fortress and ECM).  Truth be told
meta information is a key ingredient to controlling how aspects are applied
to the component.  The container can decide what to do with the information.

As we delve into the arena where the containers themselves are made up of a
bunch of privileged components, we can have the container adapt to the way
we want to work.  This is in sharp contrast to huge component standards like
EJBs and servlets.  The relationship between container and component also
provides natural places to apply cross-cutting concerns like performance
monitoring, management interfaces, remoting components, and more.  As long
as we have an agreement that can be satisfied in some way, everything can
work together.

It would be like us adapting our existing bank to now work with Quicken without
having to go into the bank internals and changing its infrastructure.  In
essence, Quicken would be able to issue a "Quicken Bank Extension", and your
bank would be able to load and use that extension so that you can now access
your accounts through Quicken.  It places more power back in your hand, without
having to give up things you have grown to appreciate about your bank such as
the tellers.

New and emerging component architectures are attempting address other issues
like providing components in a typesafe manner, minimizing the feel that a
piece of code is managed by a container, and in general making the use of
components easier.  Each step along the way has a reason for existence.  Those
who have simple needs should not be penalized, but again we don't want to go
backwards and let the container dictate how we should develop our components.
There are ways of extending how the container manages component instances that
can get rid of the need for most of our interfaces in Avalon 4.  For example,
the container can do some magic to read the meta information (using reflection
or attributes) and generate a factory that will safely create new instances
of that component each time.  That factory can be plugged in to something
that manages component instances.  Notice that the logic to handle the component
lifecycle and the component lifestyle can be made completely separate.  That
way we can apply the same lifestyle (singleton, pooled, etc.) accross all
components whether they are EJBs, Avalon 4 components, PicoContainer components,
or something new.

The important thing to realize in the world of writing components is that
with all the possibilities, we have to weigh it against what is *simplest*
for the task at hand.  If the one aspect of simplicity means that we have
to trade container complexity for component simplicity, then we favor the
component.  In the end, simplicity is an elusive creature and we will always
find a better way of doing things.

By leveraging the concepts and ideas that have proven themselves to work,
we can come up with a set of rules of conduct to put together the nano-kernel
(smaller and simpler than a micro-kernel).  That way simple features can be
added to the container until you have what you need.  We can have the assurance
that feature X will always be applied the same way.  That means that we can
confidently write components that take advantage of feature X.  The nano-kernel
just needs to know that feature X is required for the system so that it can
do its job appropriately.

All our musings on component architecture are just that--musings.  When we
start working to make our musings a reality things change.  We need to ask
ourselves if something makes our lives easier or not.  If I have simple
needs, do I really want to have a steep learning curve?  The user should be
able to get up and running without having to think hard.  Everything else
is stuff that helps them understand what is happening on a deeper level.
I don't think any of us qualify as being the naive user--we know too much.
We can fix some itches that really have been around a while.  Beyond that
we need someone new to components to really let us know if things are as
simple as they should be.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] Musings about Component Architecture

[Paul Hammant <Pa...@ThoughtWorks.net>]

Berin,

> [...] We can fix some itches that really have been around a while.  
> Beyond that
> we need someone new to components to really let us know if things are as
> simple as they should be. [...]

Well it never is for newbies.  What we (Avalon-hat) lack is components.  
Some of that was coercing other teams to rebase to Avalon and, more 
importantly, embrace IoC. Another part was to write some comps 
ourselves.  Our ToR is no longer about comps though.


-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org