Avalon's Story

First things first, what is Avalon?

This isn’t a simple question but here’s the story—Avalon is about component – container programming. You can often break a bit of software up into various “components” which are also sometimes referred to as “aspects” or “services” (in that the component provides a service to other components). Think of an automobile. You can break down an automobile into several components. The exact resolution of component break down depends on your point of view. In other words, one might see the car components as including systems like the engine, the body, the wheels, and so on. Likewise the the engine itself can be decomposed into smaller component systems. This is what I mean by resolution.

The same is true of software projects. All but the simpliest applications can be broken down into components. These components can be something like a logging system (sends messages to a log), a socket handler (handles network connections), or a particular piece of business logic (perhaps a transaction handler for stock transactions). One can easily see that in a large application there can be many components. These components will inevitably need to work with one another. This adds another layer of complexity. Without care, one quickly ends up with a tangled mess of components wired to other components in which a simple change in one can cause an ugly ripple effect through out the rest of the code.

To solve this, developers use “component oriented programming” which is essentially a method of programming where one uses a number of techniques to control this complexity. Central to COP is the idea of a container which does the dirty work of managing component inter-dependencies, lifecycle management and configuration. Since control is then in the hands of the container instead of the components this design pattern is often dubbed Inversion of Control.

So one way to think of Avalon is as an Inversion of Control framework. Right now we have an implementation of this framework written in Java, though work is underway on a C# version too. In addition to providing a base framework which defines the basic rules for components, we’ve also written several containers—ECM, Fortress, Phoenix, and Merlin. Why we wrote all of these is another story.

Point is, so many containers was both a blessing and a curse. It meant that we had somewhat specialized containers for various use cases, but it also divided our development effort, complicated documentation, and confused our users (“Which container should I use?”). Moreover, there were slight differences between the containers which made it tricky to write a componet which worked properly in all of them. To remedy this embarressment, many people in Avalon believed in some sort of “holy grail” container which would be everything to everyone and replace all our existing solutions but still offer some sort of backwards compatibility support for our existing users.

Needless to say, the “holy grail” has not been easy to achieve. There have been numerous attempts to gather consensus around a single platform but instead of cooperation we saw only the clash of egos and burn of flamewars. Several significant developers left (some of their new work can be see at JContainer.org) but Avalon remained stagnant.

For the last year or so we’ve been left with two containers: Fortress and Merlin. Active development of Phoenix had pretty much halted. Fortress represents the older and simple ECM approach to IoC while Merlin provides more features along with more complexity. One way to consider the differences was to look at the competitors. Fortress falls more along side PicoContainer while Merlin aims more for OSGi. Most of the active development was happening on the Merlin side of things.

When I became Chair of Avalon, I knew that eventually I would have to face the container issue. I knew no one was very comfortable with the existing situation, that everyone knew things could be better in Avalon, but I wasn’t sure if we could all come to an agreement on the way forward. So last week I sent an email to the PMC suggesting we begin work on Avalon 5 (we’re currently on Avalon version 4). Naturally, there were lots of concerns. Even I had concerns, but my hope was that we could identify these concerns without resorting to a flamewar and eventually come to a consensus. The major issues being discussed where:

• The complexity of Merlin versus simplier solutions
• Starting from scratch or building from existing code (Merlin)
• How to continue offer support for our users (particularly Cocoon)

There’s lots of difficult aspects to these sorts of discussions. It’s easy to misunderstand people. It’s easy to get caught up in tangents and implementation details and lose sight of the big picture. It’s easy to get frustrated and give up. In fact, we had a few developers do just that.

However, as the week came to a close I believe we were actually starting to get somewhere. Leo Sutic is working on container aspects. Stephen McConnell began digging into Cocoon to see how Merlin could be enhanced to support it. We’ve had several developers all agree on a basic way forward and I believe if we can get better support of ECM/Fortress semantics into Merlin we might have a viable solution on our hands. Which would be wonderful since I don’t think we’ve had a really good solution for users since I started in Avalon a couple years ago. We had lots of ‘half-solutions’ and mixed messages and some really genuine good intentions. While there is a lot of work left to be done, I believe this year we can finally get Avalon out of its slump and offer a very compelling platform. There’s still hope in Avalon.

A note of disclaimer—while I may be the Chair, I’m certainly not the only voice of Avalon. Others may have different understandings or thoughts of the events I’ve described. I mean to offend no one. This article only represents my personal views and thoughts. If you have something you’d like to share, please leave a comment.