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:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
