A Bright (and Radical) Future for Avalon

Avalon originally was all about the Framework. The Framework intended on defining a set of interfaces and utilites for Inversion of Control (IoC) and Component Oriented Programming (COP). From it, one should be able to design a multitude of containers and applications. The core was once the “component” package which defined how components could interact with one another. In an effort to rid ourselves of nasty marker interfaces, the component package was depricated in favor of the “service” package. Thus began the horrible confusion of component and service semantics.

But let’s set the record straight: the component/service contract is all that sets the framework apart. Other than that, the framework is all about lifecycles. Yep. That’s all it is. Just a bunch of standard lifecycle definitions given as interfaces and a couple of utilities (like ConfigurationBuilder) for using those lifecycles. Nothing more sacred to it than that.

The exciting part of IoC and COP development is not in lifecycles, it’s in dependency resolution. That’s the core of IoC: how do you invert the control? That’s the issue of picocontainer’s IoC types. Do you supply via the constructor or via bean setter methods (what has recently been dubbed dependency injection) or do you use some sort of dependency registry and supply a discovery or locator service? These are the interesting problems in IoC framework development.

So this is my first proposal (and perhaps the most radical): Break up the Avalon Framework. Let’s take our own medicine and seperate concerns. Seperate lifecycles into an avalon-lifecycle framework. Create a generic way to support user defined lifecycles and perhaps include a standard set of lifecycles used by and fully supported by all official Avalon containers.

Seperate out the service package into a true IoC framework which focuses on dependency resolution. Provide support for all sorts of IoC types. But focus on just this one issue.

Doing this will open up a whole new world of opportunities. It follows the pattern started by PicoContainer (PicoContainer should be more approprately compared to Avalon framework, not Phoenix or Merlin) and I think this is part of Leo Simon’s idea in his Jicarilla project (I can never spell that correctly. How is it pronounced ?!). Moreover, using this approach for Avalon 5 should allow backwards compatibility with Avalon 4. If it doesn’t, we won’t have reached our goal of a truly generic IoC/COP solution.

There are so many interesting problems to solve in Avalon and the container world: meta-data APIs, container extensions, service location transparency, and so on. And that’s the crux of another issue facing Avalon: there are lots of problems and lots of solutions.

As I said, Avalon was originally all about the framework. There wasn’t really a focus on providing a single super container. The idea was that the framework could be reused in all sorts of containers and applications. However, as the number of containers and implementations grew, so did the confusion. Which container to use? Which way is the Avalon standard?

Since then, Avalon has been in a constant state of identity crisis. When we “graduated” to an Apache top level project status, there was an effort to spin off anything which wasn’t directly related to our core mission. Avalon had a logging framework, unit test framework, several different servers implementing a number of internet RFC protocols, a new RMI implementation, and more. We were HUGE! So, the idea was to focus. On that everyone agreed. The question was what to focus on.

And here comes the issue of Avalon as a single product versus Avalon as a community of products, or Avalon as a host for a community of IoC/COP related projects. Can Avalon support more than one container? Can Avalon allow for more than one “standard” implementation? There are certainly similar cases in Apache. Look at the Apache DB project or the proposed Apache Logging project. Jakarta has a number of web frameworks: Struts, Turbine, Tapestry. And no one is shouting for convergence to a single Jakarta Web Framework (wouldn’t that start a flame-fest. :) ).

In Avalon we have focused on trying to create a single container which is truly generic. Merlin has been adopted as the container which will eventually become this holy grail. Do I think it can be done? Maybe. In theory, we should be able to create a very generic container, or at least a very “plugable” container which with a little bit of configuration could fit most any need.

I’ll admit that I’m a bit torn on this issue. While the idea of Avalon as a single product, a single IoC/COP solution, is very appealing, I also think that it stifles other innovations or implementations. These other ideas can certainly find a home at SourceForge, Codehaus, or even Apache, but I kinda like the idea of Avalon as a home for all things IoC/COP related.

In other words, I would rather see Avalon as something like Codehaus’s JContainer than as a single product community like Apache James. Not that there’s anything wrong with Apache James or single product communities, but it seems to me that the IoC/COP world is so rich in ideas, that there’s more than enough room for multiple implementations and ideas to coexist. And I would like to see some of those ideas exist here in Apache, here in Avalon. This is especially the case if Avalon provides a framework. A framework, by definition, means multiple applications and implementations.

So, is Avalon about the Framework or is it about a Container? (Yes, there are other options, but I’m trying to build an arguement here. :) ). I know that there are some Avaloners who feel strongly about unifying all efforts behind the standard of one true Container. In that case, (here comes another radical idea), perhaps what we need to consider is putting Merlin on the roadmap for becoming it’s own top level project. Or perhaps we need a place for just framework development. But I am concerned that as soon as we tie to two too closely together, the power of the framework will be lost in the implementation of the container.

Like I said, it’s an exciting place to be and there are a host of problems so solve and ideas to explore. If you aren’t familiar with Avalon or IoC/COP development, you should stop on by. I know when I started, I was horribly confused at first. But once I got the fundemental ideas down, I just couldn’t imagine programming any other way.

Useful links:

• Apache Avalon
• PicoContainer
• JContainer
• Jicarilla
• Inversion of Control Containers and the Dependency Injection pattern

Update: you can follow some of the responses to this essay on the Avalon developers list