cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Wed, 07 Jun 2000 12:39:40 GMT
burtonator wrote:
> Stefano Mazzocchi wrote:
> <snip>
> > I _totally_ agree. Jon is a programmer and Turbine is a
> > programmer-centric environment and wants to remain as such. While I _do_
> > understand Jon's intent, we aim go a much bigger range of action.
> The only thing within Turbine that applies here are the Turbine
> screens/layout/etc.  If you are a programmer they are great.  You can
> use Turbine without this.  For example you get connection pooling,
> Logging, etc.  These were the initial goals, to be the backend of a
> website, the stuff which requires code anyway.  The Screen stuff just
> confuses the situation :(

Ok, this is probably what's consusing me about Turbine.

Tell me: are you using Turbine because provides you logical components
that you use in your web application? just for that?

Well, guys, in that case, we already designed a great solution for this
problem, it's called "Avalon" and, very modestly (since I'm one of the
designers), it kicks the crap out of any other component architecture I
ever seen. Turbine included.

In Avalon, there are three component layers:

 - blocks
 - components
 - classes

A "block" is the equivalent the pure logical part of a "service".
Examples of blocks are "Persisten Object Store", "Logger", "Connection
Pools", "XML Database", "Thread manager", "Authenticator" and so on.

A component is a smaller object that is used to create blocks.

A class is a regular java class.

If you visualize a server (as software) as a computer (as hardware),
avalon is the equivalent of the case (metal frame, power supply,
buttons), blocks are the equivalent of the different hardware components
(boards, DIMMs, disks, fans, power supply), components are the
equivalent of packaged integrated circuits (chips), classes are the
equivalent of collection of transistors that perform some digital logic.

Cocoon uses both components and classes. Cocoon will also be a block.

Each block can talk to Avalon to request the instance of another block
to perform some operation.

So, for example, let us suppose we have these blocks

 - tomcat
 - cocoon
 - james
 - logger
 - connection pool
 - thread manager
 - persistent object store
 - volatile object store

plus these network connectors

 - HTTPConnector
 - AJPConnector
 - SMTPConnector
 - POPConnector
 - IMAPConnector

Can you see the picture yet?

I'm sure you start to get the idea, but let's see the details...

What you used to call "Tomcat" (i.e. a single java application with
pluggable web applications), now it's a graph of interconnected blocks.

 net -+-> HTTPConnector -+-> tomcat -+-> logger 
      +-> AJPConnector  -+           +-> thread manager
                                     +-> per. object store

while JAMES is

 net -+-> SMTPConnector -+-> james -+-> logger 
      +-> POPConnector  -+          +-> thread manager
      +-> IMAPConnector -+          +-> per. object store

Now, if we extend servlets to provide the Avalon instance, we create a
servlet that is able to connect to Avalon to have instances of other
blocks directly, for example, to generate hot-mail like web-applications
without having to emulate the IMAP protocol.

Ok, I'm sure now you get the picture... but let's look at what this
framework could do for us:

let us suppose we have the above Avalon running on our system. Now we
want to install JetSpeed (which we suppose to be Avalon-aware). What do
we do?

We download the "JetSpeed deployment descriptor" (nothing like the
Servlet 2.2, I just used the same name here to show you), which is a
very short xml file (a few kb) it tells you:

 This is the deployment descriptor for JetSpeed 2.0.34

 JetSpeed requires:
  - an instance of the block org.apache.cocoon.Cocoon, version 2.0+
  - an instance of the block org.apache.avalon.Logger, version 1.1+
  - an instance of the block org.apache.turbine.ConnectionPool, version

 JetSpeed package can be found at

 and the installer class is "org.apache.jetspeed.install.Installer".

This will fire some events inside your Avalon:

 - if all the required components are present go on, otherwise, contact
   which will provide you a web application that returns you the latest
   and greatest block deployment descriptor that is compatible with the 
   one you requested.

 - once all the blocks are installed recursively go on
   (note that the process should be watched for loops but since the
    number of blocks is relatively small even for very complex sets
    this should not cause too many problems)

 - copy the jar package in the library directory, request server 
   suspension (if required by the deployment descriptor), adjust the 
   internal classloader and run the installer class.

And that's it, what you need is a network connection available during
the installation process.

Also, if you know that a bugfix release of some of your blocks is
available, you simply tell Avalon to update itself and it will do
without even human intervention.

Back compatibility will be encoded in strict versioning: this means that
if you have a block with version 2.0.32, it will be "guaranteed" that
version 2.0.589 is back compatible with the block you have and just
provides bugfixes or enhancements that don't influence back

On the other hand, version 2.1.00, will not be back compatible and
Avalon will _not_ replace your current block to avoid breaking what's
working. It might tell you that both 2.0.37 and 2.1.00 were released and
let you choose.

Avalon, unlike any other component framework, is designed for both users
and developers. Users get the ability to do single click installations
of new software, much like you plug in new boards into your PC. And
developers can _reuse_ other projects or libraries without having to
worry about their deployment or versioning or back compatibility issues.

Avalon is CPAN+RPM+JavaBeans+a_grain_of_salt

Of course, this comes with a price: everybody must be aware of it and
follow its design patterns closely.

I know there will be issues with this, but so far we didn't deal with
them because there was no Avalon implementation available (not even
detailed documentation, for the matter)... but James is starting to come
up _real_ nice and it's fully based on Avalon.

Also Cocoon is showing how the internal components patterns work very
well and can simplify development as well as increase parallelization,
much more than simple classes or beans.

The idea is:

- JAMES requires Avalon and will show it's power directly.
- We'll make Cocoon Avalon-aware and provide CocoonMailet capabilities
thru James
- This will show the tomcat people what this means and hopefully (we are
already talking to Craig about this and there is a general agreement)
Catalina will be Avalon-aware or will provide wrappers for
- At this point, I'm sure Kevin will die to make JetSpeed Avalon-aware
and use its blocks just like it uses turbines services today.

Turbine shares ideas with both Avalon and Cocoon but was created to use
useful _now_, unlike Avalon and Cocoon that were system research.

[side note: on /. they quote an article from some guy at Bell Labs
saying that software system research is dead and open source is just
copying Microsoft. While it might be true on many fields, I think this
is the biggest bullshit I've ever heard. And, yes, you are allowed to
quote me for this.]

Anyway, at the end, I think you can tell why Jon dropped college and I
still don't (even if I don't like it anymore) :-)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message