Cocoon container strategy?

[Stephen McConnell <mc...@apache.org>]

Marcus Crafter wrote:

>On Tue, Sep 24, 2002 at 04:10:04PM +0200, Carsten Ziegeler wrote:
>  
>
>>Ok, I think we should have a look at a features list of fortress
>>and merlin compared to the ECM.
>>
>>

I thought it may be a good idea to bring up some of the issues I see 
concerning ECM/Cocoon migration. First of all - a disclaimer - I've only 
recently signed up to the Cocoon list and I've only been using Cocoon 
for a couple of months - on the other-hand, I've been looking into the 
Cocoon implementation and ECM related issues and I've been thinking 
about future development - in particular the deployment of Cocoon in 
Merlin as a peer service amongst a bunch of other business level 
components. As such, my comments may be out-of-sync with current 
thinking - so please feel free to correct me if I'm heading of in a bad 
direction.

Firstly - my understanding of the Cocoon/Avalon/ECM relationship. Way 
back at least a couple of years ago - there were two different 
approaches to component management in the Avalon community. One approach 
was ECM, the other approach was Phoenix. ECM represented a dynamic 
request model (passing service interface names into the lookup 
operation). The Phoenix approach leveraged meta information and enabled 
role names to be scoped relative to the consuming component. I 
checked-out both ECM and Phoenix in relation to my own service 
management requirements at that time. I never really grasped the role 
management stuff in ECM and preferred the cleaner meta-model approach in 
Phoenix. As a result, I build and deployed many Phoenix based components 
as part of a B2B application. In doing this I ran into a number of 
limitations within Phoenix that prompted the development of Merlin 1.0 - 
a container focussed on running a target component (without all of the 
configuration and assembly complications). Merlin 1.0 achieved this 
objective and has been in production use within dynamic component 
deployment scenarios for about 12 months now. However, there were 
limitations within Merlin 1.0 that let to the launch of the Merlin 2.0 
project (under the excalibur/assembly package).

Merlin 2.0 took the principals of automated assembly from Merlin 1.0 and 
added the following features:

- a continer hierachy
- deferred activation of components (and dependent components)
until the service is requested
- full support for singleton, per-thread, pooled and transient
lifestyle policies
- logging, context and configuration management
- the ability to declare packaged deployment profiles
- a full meta info and meta data API
- addition of lifecycle extensions
- ability to programmatically add and deploy new components at runtime
- programmatic container deployment
- container based classloader management
- extensions management

But lets get back to Cocoon - what we have in the Cocoon code base is 
Cocoon "the container" which is currently implemented by an extended 
ECM. This is problematic because the ECM isn't really a container - it 
is a complicated component manager. This brings up the migration 
strategy - moving Cocoon from its current ECM based implementation to a 
proper container architecture. I don't think that the right thing 
"today" is to choose one container or another - in particular, while the 
current Fortress and Merlin containers do similar things, they approach 
the same problem in different ways - present different benefits - imply 
different design decisions.

Selecting Merlin or Fortress today would slow down Fortress/Merlin 
convergence and co-development activities - but more importantly - it 
bypasses important questions that need to addressed with respect to the 
Cocoon architecture. In both the Merlin and Fortress case (but much more 
so in the Merlin scenario) your looking at a transition to meta-based 
component management. This has an impact on the overall design of the 
core of Cocoon - and that's much more critical.

My suggestion would be setup a separate project dealing with 
"meta-based" Cocoon trial and validation. That project should be able to 
establish the scope of formal container functional requirements. This 
will identify the container you need - things that Merlin provides such 
as dynamic component deployment are unique to Merlin - if that a 
requirement then what you really want is a couple of potential solution 
- putting in place such a project would allow the identification of 
those requirement - and I'm confident you would end up with either (a) a 
single container solution (based on a converged Merlin/Fortress), or (b) 
Merlin hosting Fortress, or (c) either Merlin or Fortess both capable of 
handling deployment of portable components.

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org