avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: organisation of avalon subprojects
Date Sun, 30 Jun 2002 21:16:40 GMT


Leo Sutic wrote:

> The tendency is to start a subproject (Avalon) and then another 
> subproject under that (Excalibur) and then projects under that 
> (MicroContainer) and so on. I could devote some hundred lines to this 
> and the reasons for the process, but that's neither here nor there...
>
> Anyway, the result is that the scope of the Avalon project has grown 
> immensely - it is not just a framework, it is a replacement for RMI 
> (AltRMI). It is a Database (AvalonDB). In no way do I want to 
> criticise these projects, but do they really belong under the Avalon 
> umbrella? Are they really not projects at the same level as Avalon 
> itself?
>
> Another issue with this is that doing this walls us off from the rest 
> of Jakarta. Avalon becomes a Jakarta in scope - self-sufficient in 
> itself and utterly isolated. I want to see Phoenix-based apps on the 
> front Jakarta page. That's the only way to spread Avalon through Jakarta.


Agree with the principal - object to the approach.
Getting the spread means delivering applications that work against a 
solid base - the solid base in the Avalon world is primarily the 
framework.  Phoenix is  in alpha today - stable - nearing beta - 
potentially (preferably) facing internal reworking to synchronize with 
containerkit. ECM is declared as going the direction of the dinosaur, 
Fortress is proclaimed as the replacement, MicroContainer pups up on the 
screen - early stage discussions are moving forward on cross-container 
interoperability - which today is totally out of scope - there is lots 
to be done in solving the back-office of Avalon (containers etc.) and 
that needs to be done in a focused environment when people are sorting 
out similar goals. Spreading Avalon today means destruction of the 
community.

>
> As Pete C says, I think we should slim the Avalon project 
> *significantly*. And now I am talking about some chainsaw-grade 
> reduction.


Put away the chainsaw and think instead about the words 
"consolidation".  Go back to MicroContainer and rip out the lifecycle 
processing code - put in place something from a common codebase - reduce 
the duplication.  Phoenix has already done this, Merlin is 
transitioning, if you do it you reduce unnecessary code - that 
simplifies things - lots of little actions like that will have a big 
impact.  The second and really important thing to consider is community 
growth. If you take a look at 
http://home.osm.net/technical/avalon/trends.html you will see that the 
Avalon project is steadily building.  With the resolution of reusable 
components I'm very confident that we will see significant jump in 
growth - because all of a sudden you will see components that are 
formally complete and consistent and that means reuse and that means 
value an value means attention and attention means commercially 
interesting.  But we are not there yet - its still in the nurturing phase.

>
> With MicroContainer a new possibility has emerged: All Avalon 
> components previously in Excalibur can move to Commons. I am currently 
> thinking through what restrictions MicroContainer puts on the 
> components it manages, but it appears to be quite few. 


Providing we limit ourselves to non-meta based components.  Sorry Leo, 
but MicroContainer will not run ANY of my components - NONE. For the 
sort of things I'm doing it is only valid for the simplest type of 
component.  I'm not complaining about the work you have done - but its 
way too focussed on the the ECM style/pattern of component usage to be 
usafull in a general context - and that is the big concern - you end up 
propagating the informal component model - and the proliferation of 
components that will not work across other containers.  That's the 
important thing right now - eliminating those "semantics" gray areas - 
getting this stuff really solid so that users can use the tool that best 
matches the task. 

> I have already made DataSource work, and I think I can do the same for 
> just about any component in Excalibur.
>
> MicroContainer would work with Avalon/Apps, but it seems a bit silly 
> and palindromic to provide a non-Avalon wrapper for a wrapper for 
> non-Avalon applications...


Slow down a bit.  MicroContainer has nothing to support components with 
formal dependencies.  I can guarantee you that MicroContainer will not 
support the Avalon/Apps suite of components because it has NO 
UNDERSTANDING OF FORMAL DEPENDENCIES AND SERVICES.  I said that in big 
letters because I really think that we should be a lot more strict about 
addressing limitation and potential of different activities in a much 
more consistent manner.  That is the critical all import key - 100% 
reusable components - nothing less.

>
> So I see:
>
> 1. framework
> Avalon Framework interfaces and reference implementation.
>
> 2. containers
> 2a. common container code (metainfo, etc.)
> 2b. microcontainer
> 2c. fortress
> 2d. phoenix
> Again, this is my 3-container approach.


What about Merlin? - Shouldn't it be included with the three musketeers 
- or I should I head over to the axis-of-evil?  Seriously - I would like 
to throw the "three-container-approach" a long long way away.  I don't 
want to think about different containers.  I do want a common container 
solution and that would involve (a) completing the containerkit core (b) 
building services around that core, and (c) providing tools that 
leverage those services.  Those tools would provide solutions to 
different users - tools such component documentors, application assembly 
generators, validators, deployment packagers, component and application 
execution for the developer, an application server, application and 
component motoring and analysis, etc., etc. With any luck - Fortress 
will be rebuilt or at least broken down into a set of services that 
leverage the container core. MicroContainer needs to be reviewed in 
terms of its immediate value against potential damage through component 
fragmentation.  Merlin (yes - its a container too) is already being 
totally re-written to leverage containerkit and its structure is being 
broken out into general assembly services with the objective of 
eliminating the which-container issue.  Bottom line - Phoenix is 
restructuring - Merlin is restructuring - Fortress needs to restructure 
- is there a trend here ? ;-)

>
> 3. component directory
> This is a list of components that work with Avalon containers. This is 
> basically Apps + Excalibur + all components in Commons that we export 
> from Excalibur with MicroContainer. The actual components are *not* 
> stored here unless they are wrappers for non-avalon components (like 
> some of the current Apps). It is basically a list of "this is the 
> stuff you can put in your container. 


 I have to confess that my use of Excalibur has been limited to 
utilities. Can you provide a summary of the different "components" that 
exist in Excalibur.

>
>
> 4. site
> 5. sandbox
>
> The 4 and 5 is basically just for developers. So a newbie user comes 
> in and sees this:
>
> 1. Get the framework.
> 2. Check the list of containers (all 3 of them). Pick one that suits 
> your needs.
> 3. Pick all the stuff you want to put in your container.
> 4. Good to go!
>
> Like Pete, I'd prefer just one container. But given the different 
> requirements for containers I don't think "one single container" will 
> work. I do think that all containers will be able to run all 
> components, but the way they are managed and the grade of committment 
> to Avalon architecture differs - and I do not see how that can be 
> avoided.


This has to be solved - existance of different semantic approaches to 
component management mean that components are designed and implememtated 
today relative to a target container family.  We have two semantic 
models - the ECM/Fortress/MicroContainer model and the 
containerkit/Phoenix/Merlin.  Either of these two approaches must die or 
we must make a formal distrinction between them and live with the 
consequences.  

>
> Maybe we can provide some three-point checklist for the containers. 
> Like (I'm sure we can argue over the list below. I'm only quite 
> certain about MicroContainer and its "upper limit" against Fortress. 
> As for the upper limit of Fortress, I'm a bit unsure.):
>
> MicroContainer
>  + You are primarily interested in using one or two Avalon components 
> in another architecture.
>  + You are not interested in the Avalon architecture and would like to 
> know as little as possible about it.
>  + Basically: Just give me the darn component! 


And hope like hell its not a component that expects anything substantial 
from its container - i.e. no meta support. Very limited validation - no 
enforcement of a formal compoenent defintion - usefull for lifecycle 
handling.

>
>
> Fortress
>  + You are considering using Avalon for part or all of your application.
>  + Your application is not a stand-alone server or server application.
>  + Basically: You are writing a servlet. 


And hope like hell its not a formal component that you using.

>
>
> Phoenix
>  + You are considering using Avalon for a stand-alone server.
>  + Basically: You are writing an entire server. 


And hope like hell it is a formal component or your hosed.

>
>
> Maybe even a checklist. Check all checkboxes, click on submit, and 
> we'll tell you what container you want. :) 


Today - do the checklist and you will end up with one or more containers 
YOU MUST USE because of inconsitent and incompatible component models.

>
>
> Other points:
>  + Logkit out of Avalon and to top-level or Commons.
>  + Testlet DIE DIE DIE kill it already for the love of God. 


I agree - Testlet should disappear.

>
>  + Excalibur/Event (SEDA/SILK) to Framework or sandbox. 


Sandbox.

>
>  + Excalibur/Command (SEDA/SILK???) to Framework or sandbox. 


Sandbox.

>
>  + AltRMI to top-level within Jakarta 


There are actually several Avalon Apps projects that could escalate - 
but the bottom line here is that those issue noted above must be sorted 
out. Those projects are reusable components and the infrastructure needs 
to exit beta before the majority can consider exiting the Avalon.  That 
means working on containerkit - it means re-engineering all of the 
current containers (even MicroConbtainer:-) ).

It means every component coming out of Avalon passes a component 
conformance test-suite.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message