avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: One Container Revisited
Date Mon, 01 Jul 2002 05:53:12 GMT

Pete:

Given that ...

1. you cannot realistically use Phoenix for embedded component management
2. you cannot use Fortress/ECM/MicroContainer for components with meta
3. you cannot use Phoenix/Merlin for ECM style component lookup

Which container do you want to be the "one" - 
MicroContainer/ECM/Fortress/Phoenix or Merlin. No matter which decision 
you take you end up with an incomplete solution. That's my point - the 
one container principal does not work and will drive against innovation 
- and this is innovation area. What really matters is consolidation of 
the achievements in MicroContainer/ECM/Fortress/Phoenix and Merlin - and 
that means container authors getting there heads together and sorting 
out what the back-office of component management means. There isn't one 
solution today - there is no back-office spec. Until that spec is built 
and a reference implementation established - there will never be one 
solution.

Pete Carapetyan wrote:

> Stephen McConnell wrote:
>
>>> If the other Tomcats would be mostly ignored, what's the point of
>>> spending precious volunteer developer time on them?
>>>
>>
>> Because the types of container that exist today are in general 
>> addressing very differnent problmems. Phoenix is an app-server that 
>> runs an application where an application is defined as a package of 
>> components, supporrting resources and assembly directives - Merlin is 
>> a component runner that just runs up a component + all of its 
>> dependents - greate for development and massively simplified 
>> deployment. Fortress is focussed on simple components (relative to 
>> dependencies) bu provides better support for stuff relating to pooled 
>> components. All of the containers listed here represent end-points in 
>> the deployment cycle - Merlin II is addressing the issue of a 
>> container that is a component in another container's idea of the 
>> word. The point in spending the time is that we are sorting this 
>> stuff out - what is container - what should a minimum container be - 
>> how to seperate container operation form functionality - multiple 
>> contains mean we have validation of differnent approaches based on 
>> different objective.
>
>
> And that paragraph just about says it all for me. Jeez Louise. Is this 
> complexity for the sake of complexity or am I just going cookoo? I'll 
> second Haberman's motion that good design means a second version is 
> not warranted in most circumstances.
>
> But wait, this next paragraph is even better.
>
>> Thin what an improvement it would be if you could write an ant task 
>> that automatically executed your single servlet class - did the 
>> compilation of the JSPs, did the context management stuff - and 
>> provided lots of debugging info - then imagine that Tomcat had 
>> another tool - a tool to runup the entire packaged web app and let 
>> you validate things in a context closer to deployment - then imagin a 
>> third tool Tomcat itself where you run you web app in a mixed 
>> environemt with other applications - and still as an ant task - still 
>> wioth lots of debugging information - and then finally, imagine a the 
>> final refernce Tomcat - the thing that runs your application out in a 
>> customer environment. Tomcat does not deliver this - Avalon can. 
>
>
> You forgot to mention the new college degree program in Avalon. 
> Complete with 17 courses of instruction, and four equal department 
> heads to compete against each other on which one was the real path to 
> the holy grail. But it's a six year program, couldn't get it done in 
> four.
>
> The reason Avalon is complex is that committers get a great deal of 
> personal satisfaction from making it complex. The only thing that 
> could be better would be to make it even more complex. Wait ! Here's a 
> new feature with 3 new permutations. Let's add that too! No, let's 
> start a whole new container. That's the ticket! Or should it be 3, one 
> for each permutation? Hmm.


<advertisement>
Go check out Merlin - its all about eliminating complexity. I can write 
a new component, and run it with no container configuration - just an 
ant task and a target component class name. If I don't want to use ant I 
can do the same thing from the command line. If I don't like that I can 
embed it inside anther component. And guess what - its all documented 
and does not need a degree in anything :-)
This isn't about complexity - its about simplicity.
</advertisement>

>
> Do one thing. Do it well. Avalon is about good engineering, not more 
> engineering. There is a difference. 


The Avalon component model is looking good. The API for the client is 
small, consistent and complete. However, two operations on one class are 
the subject of a lot of debate - and guess what - those two operation 
relate to the interaction between the component and its container. If we 
look back into the not so distant past - two different approaches were 
taken by two different communities in the development of tools to handle 
component management in two different application areas - one was 
Phoenix and the other was ECM. These two "containers" were basically 
referred to as applications - then some time later another two 
applications emerged - Fortress and Merlin. Why? Fortress came about as 
an evolution and improvement in ECM based component management. Merlin 
came about as an evolution and enhancement of the development approach 
related to Phoenix based components. As a result of that - the subject 
of the "container" came to the forefront. What is a container? What are 
the differences in the semantic assumptions that exist between the 
Phoenix family and the ECM family with respect to components? Those 
things have been thrashed out (and continue to be thrashed out) on this 
list. Throw into this the fact that the content of a common container 
framework is not set in concrete - it's emerging.

The premise of doing one thing and doing it well is fine providing we 
know *what* that one thing is - and that we *understand* what doing it 
well really means.

Cheers, Steve.

(who's busy digging into *what* and working on the *understanding*)

-- 

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