[RT] Atlantis - More than just a dead city ?

Hi,

I had a boring as hell day today and had a bit of time to think. 
I began thinking how would be the best way to support the different
model proposed by the EAS project. I was also peripherally thinking
about how I could generalize this to support Pauls needs with respect 
to jesktop (He had expressed some concerns regarding SAR format 
aswell). 

Up until now I had been trying to generalize the Camelot Container API
in some manner to satisfy these needs. If you recall that when I was 
initially playing with and developing camelot I added in classes and 
interfaces like Application, ApplicationDeployer etc. However I would 
invariably end up removing the classes because they did not really
fit into the Camelot model.

What is the Camelot model?
--------------------------

Camelot was basically a container API. It defines classes and patterns 
that work when you have a Container that contains other Components. It
describes methods that can be used to deploy components into a container, 
methods to register components meta-data + locations and methods to 
extract components from archives.

How did it differ from the Application model?
---------------------------------------------

Until recently I hadn't really thought about what was different from 
Applications and why they did or didn't fit into the Camelot model. 
Just recently I had a "hit my head on the toilet to come up with a 
great idea" experience (ie had a dull day at work ;-]).

The camelot model decrees a two level approach. Namely

Container   -------->    Components
            contains

The Application model was different, it had a 3-layer approach. Namely

Kernel   -------->    Applications   -------->    Components
         contains                    contains

This abstraction could be applied to a number of different architectures.
For instance there is the 

AvalonKernel   -------->    ServerApplications (SARs)   -------->    Blocks, resources, config

in the current Avalon CVS. There is also 

ServletEngine   -------->    Web Applications (WARs)   -------->    Servlets, jsp files, content
EJBContainer   -------->     EJB Applications          -------->    EJBs
etc.

You will notice that as a product evolves it generally evolves from 
a 2 layer approach to a 3 layer approach. Look at the evolution of 
servlet spec for an example. Another example would be Avalon itself 
which evolved from a a Block container to a Application container 
(with the Application containing Blocks).

I could see that in the future as Turbine and Cocoon2 evolve you will 
be able to install Turbine Application and Cocoon Applications into the 
Turbine "kernel" and the Cocoon "kernel" respectively. There was a 
request for similar functionality a while back on Cocoon list and there 
was quite a few requests for this type of functionality from Turbine users.

The terminology will of course differ from product to product. Some products 
describe the kernel aspect as an "Engine", others as a "Kernel" and still 
others as a "Server". Consequently you have ApplicationServers, PortleEngines, 
AvalonKernels etc.

Each of these approaches have very similar functionality. The components 
receive lifecycle management from the Application which receives lifecycle 
management from the Kernel. The kernel provides the Applications certain 
facilities and supporting functionality (hereafter termed Facilities). 
Many of these Facilities are shared between different types of systems. 
For instance most systems will provide a ClassLoader Facility and many 
operate similarly in a hierarchy such as

system  <--- common classloader <--- Application specific classloader

Some of the other common facilities offered include Security, 
thread management, "stdout" management, logging, JMX management etc. 
There may also be other types of facilities offered - such as naming, 
replication, distribution, network communication 
etc.

So what does this all mean?
---------------------------

Well if you look at the difference between Camelot and the 
Atlantis kernel. Currently Atlantis is very monolithic and can 
be difficult to work with (and has sucky logging). What I would like 
to do is fix this and turn Atlantis into a kernel "framework" rather
than a specific implementation of a Block/Sar kernel. However as I 
would also like to do a release in next few days I would like to do 
this in two stages. The first stage being pre-release and the second 
stage occuring after moved to jakarta and after next release.

Stage 1
-------

Create a new hierarchy that contains all client code to 
interact with the "traditional" Avalon kernel.

org.apache.foo.Block
org.apache.foo.Service
org.apache.foo.BlockContext
org.apache.foo.DefaultBlockContext
org.apache.foo.AbstractBlock
org.apache.foo.SarContextResources (perhaps not this??)

where foo is some name we decide (perhaps phoenix). This would be 
done so that we don't cause our users too much trouble. If they 
are just writing Blocks then this will be unlikely to change in 
near future (if ever again). We update the services to 

org.apache.bar.services.*
org.apache.bar.blocks.*

where bar seems likely to be "cornerstone" at the moment as it 
is only one that has had full positive votes ;) We also leave 
deprecated "remanents" in org.apache.avalon.services.* that 
simply extend the real interfaces. We can remove these 
deprecated interfaces/classes at some point in the future.

ie

public interface Store
    extends org.apache.bar.Store
{
}

Stage 2
-------

We rework the current atlantis so that it is less a specific 
kernel and make it a kernel framework. This would involve making 
the specific kernel live in 

org.apache.foo.engine.*
org.apache.foo.metainfo.*

It would also involve generalizing the kernel and making it modular. 
Hopefully this would have the side effect of giving us better console 
logging support and better management support. We could also generalize 
the notion of Facilities so that kernels could be assembled out of 
different Facilities.

There is also a significant difference between deploying Applications 
and deploying Components. With applications the steps could be 
generalized to 

1. Install the application. This may involve downloading an archive, 
extracting the archive to a specific location and maybe setting up 
default configuration data in the configuration database.
2. Create a Entry in Kernel for Application. Prepare the entry 
for assembly.
3. Deploy the components into the Application.
4. Start the application.

You will notice that Deploying applications actually contains the 
concept of deploying components int containers. Each of these steps 
will be generalized if possible. 

I have recently had a few requests for the feature of having an 
Application spread across multiple directories. For instance often 
an application will be shared between multiple "users". Consequently 
you would end up with one directory that contains per-user information 
and one that contains the "shared" data. All these things should be 
considered with this framework.

Anyways I have a whole bunch of other ideas running through my head 
about this type of approach if you guys think it would be worthwhile.

Pete