RE: A Merlin Top Level Project

> -----Original Message-----
> From: Rakesh Jain [mailto:[email protected]]
> Sent: Friday, July 23, 2004 08:18
> To: Avalon framework users
> Subject: Re: A Merlin Top Level Project
> Importance: High
> 
> As I understand, Merlin is an implementation of Avalon framework, plus
> much more. When Merlin becomes a TLP, it will still be dependent on
A-F,
> perhaps as a user. Now, if A-F guys do any changes in framework, which
are
> not compatible with Merlin's then implementation, what we will do?
> Basically, we will ask them to upgrade the version so that we stick to
a
> compatible version of A-F. This is true with any framework, which is
> already being used. So, why this can't be done now, so that other
projects
> don't have to worry? Political reasons?
> 
> I used Fortress before, and recently using Merlin, and liked Merlin a
lot,
> as well as interested in its future plans, so, would agree with you to
get
> it as TLP and whatever is good for it, but would like all of us to
think
> ahead and see if we will come into similar situation after few months
of
> Merlin TLP ??
>

Following on from Niclas email ...

If you consider framework as vector describing the evolution of the
client view of a component contract we need to consider where the vector
is heading:


  4.0             4.1   4.1.2    4.1.3     4.2        X.X
   |---------------|------|---------|-------|----------|-----> ?


Keep in mind that framework is not complete.  Evolution of framework
will probably result in increasing the completion factor.  If that
evolution is driven by Merlin then the evolution will be heavily
influenced by a combination of framework plus meta-info.  Secondly, any
change (for example the 4.1.3 to 4.2) introduces an overhead on other
container developers to maintain compliance with the framework
specification (which is a source of tension).  

If we look at were the framework specification is incomplete - its areas
when incompleteness provides a lot of latitude for container developers
(context and service dependency management stand out), so on one hand,
completeness is good, but it also inhibits variation.

There is a way to deal with this such that client usage of framework is
preserved and protected.  In particular, if you assume that framework is
the computation contract, then one can argue that a particular
containment system is responsible for declaring a component model.

In the case of the merlin system things basically break down as follows:

   |--------------------------------|
   | Framework 4.2 plus Meta 2.0.0  | <---- the client contract
   |--------------------------------|
                 |
   |--------------------------------|
   | Composition 2.0.0              | <---- the meta model
   |--------------------------------|
                 |
   |--------------------------------|
   | Activation 2.0.0               | <---- the runtime
   |--------------------------------|

The merlin system is largely defined by the composition system.  That
system is based on generic framework patterns and the specific semantics
resulting from the combination of framework 4.2 and meta 2.0.  The
merlin team know that there will be on on-going process of semantic and
model enhancement and at some point I'm confident we will break out
sub-systems within the composition model that are linked to a particular
component contract (e.g. Framework 4.2 versus 5.0, or perhaps a native
Merlin model, whatever).  In practice this will mean that meta-info will
need to declare contract "assumptions" and that the composition system
will map in the appropriate model sub-systems.  This will allow for
concurrent execution of components that assume different frameworks and
semantics.

We already have a completely pluggable runtime that separates out the
actual deployment and management aspects.  Doing the same thing with
composition is a possibility but in my opinion it would in practice be
better to approach the problem at a finer level of granularity inside
the composition system.  But this is future thinking.  For now it's much
more a case of locking down on framework 4.2 and from there -
progressively evolving the merlin platform to a point where the notion
of 4.2 is just another piece of meta-info that merlin uses to handle
deployment correctly.

 |-------------|          |-------------|         |-----------------|
 | Composition | manages  | Containment | manages | Component Model |
 | Model       | -------->| Model v 2.0 |-------->| Avalon v 4.2    |
 |-------------|     |    |-------------|         |-----------------|
                     |
                     |    |-------------|         |-----------------|
                     |--->| Containment |-------->| Component Model |
                          | Model v 3.0 |    |    | Avalon v 4.2    |
                          |-------------|    |    |-----------------|
                                             |
                                             |    |-----------------|
                                             |    | J2EE Servlet    |
                                             |--->| v 2.2-4 ?       |
                                             |    |-----------------|
                                             |
                                             |    |-----------------|
                                             |    | Component Model |
                                             |--->| ABC v X.Y ?     |
                                             |    |-----------------|
                                             |

So, to wrap this up - we have already reached the point where we know we
will need to manage different versions of block definitions (for
example, we need to lock down on a final block spec, but allow for the
continued development and anticipate new block versions).  In effect the
same concerns exist at the 'component' and 'block' level.  The
difference is that merlin is a system capable of evolving and adapting
to meet immediate challenges, but also, it's a system capable of going
much further.

Stephen.