First up... very nice post. Very well thought out, and if I daresay, a bold step towards a bright future for Avalon. After reading and skiming through 100s of posts in the last week or so on the dev-list alone, this is a refreshing way to wrap up everyone's thoughts and dreams, and move towards raising a unified Avalon banner.
I've purposely refrained from reading any other developer's or user's response to this post. Apologies up front if this response adds very little value beyond what everyone else has already written. I find myself not having much to add to many of the *large* discussions recently after reading everyone's input, and I believe you, Aaron, are highly interested in getting feedback from all the committers on this proposal in particular.
With that said... see my comments inline below...
J Aaron Farr wrote:
All of this resolves around the question of "What is Avalon's mission?" The two ways I'll approach this are:
1. Community Scope 2. Framework Specification
I believe you are correct here, and this observation and the clarity with which you present it really simplifies the complexity and dissension amongst the community for me.
Let's start with community scope.
Should Avalon be a sort of "umbrella" project for multiple container implementations or should there be a single Avalon platform and/or product?
I'll probably discuss this more later, but the short answer for me is *depends*. Before you throw eggs, vegetables, and old 15" CRT monitors at me, let me explain.
If there are controls in place (i.e. framework + meta standard + TCK) that would *guarantee* Avalon-certified components could be deployed across multiple Avalon-certified container implementations, then far and away my preference is for Avalon to be umbrella for different container implementations. Certainly, I need a tried-and-true containers to build my commercial applications on, but one day I hope to build my own container if for no other reason than to just say that I did. I think the Avalon community can be *big* enough to not only be a resource that enables the business world to deploy and operate better and more reliable/scalable applications, but also serve as a think-tank for evolving software to new and uncharted territories. But that dream will only be realized in an Avalon that is operating within well-defined boundaries and structures. Chaos will prevent the umbrella model from developing successfully, IMO.
Now, if consensus on the these controls cannot be arrived at within the development community, then we must be severe and make Avalon a single platform community. IMO, that means rallying around Merlin, and tearfully saying goodbye to those with other container implementations to scratch. This alternative is far less appealing to me, but is better than living in a divided house. There are many major dudes here, and Avalon would suffer in their absence.
Bottom line for me is that I want to write my components ONE time and run them in ANY Avalon container. If the number of Avalon containers equals 1, then that's the trivial solution. If the number of Avalon containers > 1, then the definition and unanimous adoption of framework+meta+TCK controls is NON-NEGOTIABLE.
This question is really at the heart of a lot of the recent discussions. Traditionally, Avalon has been about the framework API. Anything not in the framework has been up for grabs for the container implementer. The great advantage to this approach is that we end up with a lot of diversity and freedom to explore a number of different solutions. This means we have specialized containers for various scenarios. You get to use the right tool for the right job.
A good and healthy thing IMO, as it would safeguard Avalon technology from falling into a local maxima. Different and fresh containers will act a mutative forces to push the technology ever more closer to a global maxima in terms of how *good* the technology can be.
At the same time, the approach has left us with incompatibilities between our own containers. You have to have a very good understanding of Fortress, Merlin and Phoenix to write an application which will run cleanly under all three. This puts a strain on both our developers and our users. I can't even begin to count the number of times someone has asked, "What container should I use?" and the question is absolutely warranted given the situation.
It's virtually impossible except for a few seasoned developers I would believe. The business world isn't going to whole-heartedly adopt Avalon technology given the current state of the learning curve. In fact, it makes the decision to flow with the industry momentum of EJB's all the easier.
I can see how someone may not be concerned with these incompatibilities. For example, Cocoon still uses ECM. As long as ECM works for them, why should they be concerned that their components don't work in Merlin (or whatever)? Why not just be pragmatic about things and just use what works?
That's right. The current state of incompatibilities from a component reuse viewpoint amonst the container implementations does not encourage or foster the migration of the user base to the latest (and we hope better) implementations. Incompatibilities such as these create fear and loathing amongst the user community, and will eventually act to siphon them off to other container technologies.
While this argument has merit, I believe it misses out on what Avalon set out to deliver. I don't believe we intended on creating a component oriented framework where reuse was a secondary consideration. Seeking to rectify this situation seems (to me) perfectly in line with our charter and mission.
Absolutely.
So we have two questions:
1. Community Scope: IoC central versus a single product? 2. Framework Specification: What is part of the framework?
With that in mind, let's risk a look at a couple "implementation details" -- specific proposals from the last week or two. Only this time, let's look at them under the light of our more basic, more abstract, questions:
Niclas's Unifying Vision
Basically, Niclas's big argument is that our components don't work cross-container. As far as he is concerned, the framework is incomplete because it allows for these sorts of discrepancies. He would like to extend the framework to include a more complete set of container-component contracts so that if you followed this specification, your component would work in any true Avalon-compliant container. This would require a TCK or two which would help lay out these rules.
Notice that this idea does not limit us to one container. As soon
as the TCK were in place, we could have all sorts of containers --
enterprise ones like Merlin, embedded ones like Fortress. The important part to this vision is a fairly strict framework. His current promotion of Merlin is simply because there's already a
lot of momentum behind it. Additionally, it may be easier to start
on one container and then branch out from there.
I'm in basic agreement with this prosposal. Let's get the container-component contracts defined and a TCK in place -- and don't stop until there is unanimous adoption amongst the committers.
And while I agree that we should initially rally behind Merlin as an initial container built on these contracts, I am also of the opinion that fairly early on, another container implementation that offers a container solution for a different problem domain (than merlin) should be simultaneously (or near-so) developed using the same contracts. My experience in interface development has taught me that interfaces mature only when very different implementations are developed that really test the *goodness* of the abstraction layer. It would also serve as a *proof-of-principal* of the write-component-once-deploy-anywhere CTQ. If that test fails, then we've essentially proved that we do the same thing we've already done a second time.
So, in our spectrum of things, Niclas's vision falls fairly strongly on the strong framework specification side, but still allows for multiple containers once the TCK has been written.
The very thing I'm eager to see.
Thus Stephen's approach, like Niclas's, is strong on the framework specification and also very strong on the single product idea. Stephen has informed me that his proposal does leave room for other containers as long as they too follow and pass the TCK.
I think there is merit for the notion, that even though multiple Avalon containers may exist (certified by the TCK), Avalon as an entity has and promotes a *flagship* container. And I think that flagship container should address CTQ's that are found in the enterprise application domain space.
Leo's Container Aspects
The aspect approach certainly allows for multiple containers, but in effect, they would all be various combinations of aspects, component handlers, and facilities. If I understand correctly this would also allow for more flexible framework constraints if one so desired -- perhaps even "pluggable" framework specifications. In this way, support could be added for the existing Avalon framework and container nuances while leaving the option of alternative specs open.
This seems like an interesting implementation approach that would allow container developers to *assemble* containers much in the same way that application developers *assemble* components/blocks to build an application hosted by a container. But I see this as a secondary to the container-component contract specification, and more of an implementation detail on how the Avalon community can effectively and efficiently support multiple container implementations. (A very worthy problem to solve, but secondary).
Keeping the Existing Containers Approach
Finally, another alternative is to simply maintain our current course and offer support for Fortress, Phoenix, and Merlin. In this case, we would definitely be supporting multiple containers, though there is certainly interest in providing better cross-container support. Of course, it is somewhat difficult to see exactly how to do that without resorting to an approach similar to ones listed above.
Let's not even go there. I don't see this as a forward-thinking approach.
Now, some final words:
We care about our users. No one wants to leave users high and dry as developers wonder off perusing some holy grail. Any change in our mission or any new roadmap would have to provide for the users of all existing containers. Such provisions are not hard to add to any of the existing ideas, so no one should get too worried that support for your favorite component or container is going to disappear. Even if we should all decide tomorrow which path to take, the existing containers would remain (though perhaps without further development) until a proper replacement existed.
Agreed.
So, you've put up with me this far. Now what?
Well, that is exactly the point. I feel before we can accept any of the proposals outlined thus far, before we can adopt any sort of roadmap, we need to have consensus on these basic issues of Avalon's mission, namely the matters of community scope and framework specification. In order to come to a consensus on this, I propose:
* We offer a period of up to one week for discussion of this matter
At the time of my writing this response, you've posted a VOTE one day after posting the PROPOSAL. Grrrrrrrrrr... bitch... piss... moan...
This can include some discussion of the merits of the various proposals; however, please avoid 'implementation creep' as much
as possible. Please state your feelings about the more general
matters of Avalon's mission. You may consider posting an email
which answers the following questions:
1. Why do I use Avalon?
Because I genuinely believe Avalon technology is the best Java server framework for developing enterprise level applications.
2. What do I feel Avalon's mission to be?
To provide this framework and at least one enterprise level container (and other containers if necessary) to a user community AND stand in a place of mentoring/instructing/guiding/directing/facilitating a place where component re-use and warehousing is a reality.
3. Where do I see Avalon by the end of 2004?
I'd like to see the component-container contract and TCK defined, unanimously adopted by the committer community, and developed -- along with a *flagship* reference container built on these contracts. A second container and the beginnings of a rich set of re-usable components would be gravy.
4. How do I feel about Avalon as an umbrella project vs. a single
product?
I support the umbrella model, provided the component-container contract and TCK is adopted.
5. Should there be a formal framework specification?
Absolutely.
6. If so, what should it consist of?
A4 framework (component lifecycle, etc.) plus meta standards at the very least. I'd entertain other extensions as well, maybe for message-driven and persistence lifecycle models, but I'm not sold on it.
I appreciate your patience with me. I hope that I have clarified some ideas here and opened some minds. I may follow up with some further emails exploring the "why's" behind each proposal and a better break down of the various pros and cons. While I'm not certain we can please everyone, I do believe we can come to a common solution and move forward in Avalon without every again worrying about our mission, our vision, or the road ahead together.
Let's do it!
-- Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
