avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Component Meta Model Wars--Resolution time?
Date Tue, 20 Aug 2002 17:14:57 GMT


Berin Loritsch wrote:

>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>Berin Loritsch wrote:
>>
>>    
>>
>>>Before we go too far down the holy grail crusader mentalities, lets 
>>>keep in mind that neither ContainerKit nor Merlin's Meta 
>>>      
>>>
>>Model (which 
>>    
>>
>>>is what it is) has been voted on or accepted as the standard.  
>>>Therefore NEITHER deserve the moniker Avalon Meta Model.  
>>>      
>>>
>>That cannot 
>>    
>>
>>>be given until we have decided on a standard.
>>>
>>><rant>
>>>The problem with excalibur as it stands is that there are too many 
>>>forks of functionally equivalent things.  We have a fork of 
>>>ContainerKit, a fork of Merlin, and a fork of the proposed 
>>>      
>>>
>>extension mechanism.
>>    
>>
>>> 
>>>
>>>      
>>>
>>I don't think this is correct.
>>
>>* there is a fork of a part of containerkit dealing with meta-info 
>>management and container independent meta management resources
>>    
>>
>
>But a fork nonetheless
>  
>

Yes - but lets please be clear about what was forked.  The fork was on a 
specific sub-set.  Whan use use the term containerkit you are refering 
to a lot of backage - a lot of content that has nothing to do with 
container interoperability.

>
>>* there is no fork of Merlin that I am aware of
>>    
>>
>
>A fork is something that started in one repository and for some
>reason is moved to another while the original code is still maintained
>separately.  Therefore, in the purest sense Merlin 2 is a fork of
>Merlin 1.
>

Exception that Merlin 1.0 (which is still in use during Merlin 2.0 
development) is not the code base for Merlin 2.0.  Merlin 2.0 was 
started on a clean sheet of paper.  Merlin 2.0 represents an evolution 
of the Merlin 1.0 concepts.  Therefore, in the purest sense, Merlin 2 is 
a fork of the Merlin 1.0 concept.

;-)

>>* there isn't a fork of the proposed extension mechamism
>>    
>>
>
>Your version was a fork of the one in Fortress.  You developed it
>independently without discussing with us why we made the decisions
>we did.
>  
>

No, that's not actually correct.

The initial extension implemetation inside Merlin was written in a way 
that look into account the meta-info and meta-data context present in 
the Merlin Framework.  Yes - there was extensive review of the Fortress 
implemetation - but it wasn't a fork.  The work from Marcus in Fortess 
supplied the inspiration but the implementation focussed on resolving 
how to achieve equivalent functionality in a meta driven environment. 
 When that excersice was completed - thare was discussion and exchange 
between Marcus, yourself and myself concerning the development of a 
common set of interfaces that would enable the different implemetation 
approachs to be interopperable.  

>  
>
>>There are some actions to seperate the container indepednent 
>>resources in the Merlin project concerning the proposed 
>>lifecycle management and the meta info management into seperate 
>>packages that are independent of the Merlin package.  This is 
>>not forking - this is just putting thing in place so that they 
>>are more easily re-used by other projects.
>>
>>    
>>
>>></rant>
>>>
>>>Now, as the table that was in another thread showed, the 
>>>ContainerKit Meta Model and the Merlin 2 Meta Model are 
>>>largely equivelant.
>>>
>>>      
>>>
>>Sorry for being padantic - but there are massive differences. 
>> The minor differences your referring to concern the meta-info 
>>model (the type level stuff).  Beyond that the containerkit 
>>resources proved unworkable in a dynamic environment.  Due to 
>>a general refusal by the author of containerkit to address 
>>needs outside of his own area a fork of a part of containerkit 
>>was made - in order to leverage the usable content.  The 
>>Merlin Meta Model is something else - it includes the Merlin 
>>container specific content - it is part of the Merlin project.  
>>It leverages the container neutral meta-info layer.
>>    
>>
>
>Then we need to address exactly how much of a system *should*
>be made dynamic.  And forgive me for being pedantic, but shouldn't
>we have just one meta model?  Merlin==Fortress==Phoenix?
>

Probably not.
Fist of all - lets look at what a meta-model contains.

  * meta-info, descibing a type of component
  * meta-data, describing profiles of deployment of a particular
       component type

Getting in place a common meta-info layer for an Avalon component
is reasonably strait-forward.  This has been the objective of the
work put into the excalib/meta package.

When you get into the meta-data layer you start to see very
significant differences between containers.  For example, Phoenix
meta-data boils down to the descriptions of component associations
and component configuration declared in the assembly.xml and
config.xml files.  In Merlin the meta-data is expressed under a XML
file that describes the kernel and a container hierachy, together
with explicit component declarations within a container declaration.

In effect the meta-data layer is where container inovation will occur
for the vast majority of cases.  

>
>I dislike too much stuff happening behind the scenes so that I
>have no clue what is going on.
>

I don't know what you referring to here.
Certainly nothing in the Merlin 2, lifecycle work, or meta model
work has been behind the scenes.

>
>>>The major distinction is that Merlin has support for Stage and 
>>>Extension meta info. I need some clarification on the Stage 
>>>meta info--if it is referring to Stephen's first cut at 
>>>forking the extension mechanism then it needs to die.  If not, 
>>>then I need to know what it is talking about.
>>>
>>>      
>>>
>>This is all documented.  Please refer to the following page 
>>and the respective javadoc on the meta-info types under the 
>>org.apache.excalibur.meta.info package.
>>http://home.osm.net/doc/merlin/extensions.html
>>    
>>
>
>I'll look at the document, but can you just say 'Yes' or 'No' and
>then provide the link for further clarification?  It'll make things
>quicker.
>  
>

If the question wasn't loaded you would probably get a strait answer!

;-)

>
>  
>
>>>Either way, it is important to note that *Extensions* are 
>>>just that--*Extensions*.  Therefore containers are not required 
>>>to implement them.
>>>
>>>However, if they are implemented, they should be implemented in a
>>>consistent manner.  I would be happy with a meta model that 
>>>validates that the extension can be satisfied, and if the 
>>>container does not support the extension/stages then it needs to 
>>>fail-fast and tell the developer that they cannot use that 
>>>component in the container.  The documentation for extensions 
>>>must be resilliantly clear that you cannot expect components
>>>that take advantage of extensions to work in absolutely 
>>>every container.
>>>
>>>Generally speaking, if ContainerKit does not provide validation, I 
>>>would like to see it do so.  I would *really* like to see a 
>>>merging of Merlin/ContainerKit meta info.  If there are any 
>>>blockers to that happening that are technical in nature (technical, 
>>>not political) I would like to hear it.  
>>>
>>>      
>>>
>>Technical:
>>
>>  ContainerKit meta-data model cannot be used in a context where you
>>  dynamically create associations between type profiles.  This is
>>  brought about by the problem that the entire conterkit structures
>>  are immutable.  This prevents dynamic construction and the potential
>>  for dynamic replacement.
>>    
>>
>
>Would it be able to regenerate the meta-data model when we reload
>configurations?
>

Yes.
The model currently provides support for the dynamic binding of a 
candidate service provider with a target consumer component. The 
intention is to be able to re-bind serivces so that a container can be 
dynamically reconfigured (for example, in an edditor within which an 
assembler disable one compoenent - Merlin automatically establishes 
alternative candidates and defaults, and the assemble can select 
prefered solutions or run using default solutions).

>We can make ContainerKit allow dynamic reassignment.
>  
>

There is absolutely no techical reason why not.  
However, you may run into some operation difficulties along the way.


>>  ContainerKit attempts to define too much about how a 
>>container should
>>  be implemeted, resulting in a very large redundancy of classes.  The
>>  only realistic approach to building a common container 
>>utilities group
>>  is the progressive defintion of areas of common concern, progressive
>>  collaboration between parties with different solution, and from that
>>  the establishment of sharable utilities.
>>    
>>
>
>Could you give me an example where the ContainerKit model artificially
>constrains you?
>
  * lifecycle tools proved insufficient when dealing with
    configuration and context management
  * kernel, lifecycle, processor, and verifier packages all use
    the static meta-data model (you cannot use these resources
    unless you accept the liimitations of the meta-data
    implementation)
  * imputable contructors prevent any possibility for extension
    of base classes for dynamic applications
  * assembly strategy is based on the Phoenix static assembly model
    - it does not provide sufficient flexibility for the adative
    approach used in Merlin to automate assembly activities and
    will not support the partial modification of structures - in
    Merlin the container represents someting reconfigurable - using
    the containerkit approach you would be forced to rebuild the
    entire hierachy, not just a single container


>>Operational:
>>
>>  You need collaboration for something to be common - it 
>>needs to build
>>  based on an open attribute to community ideas.
>>    
>>
>
>True.  However, if the original author believes that something should be
>immutable, it is worth our time to find out why.
>  
>

Franklly, I've spent so much time on this - the author in question has 
shown a clear unwillingness to adapt to other requirements, or even 
discuss these.  Too many -1s, too many insults, too many justifications 
such as the phrase"it's not going to happen".  Its worth spending time 
when the time spent is in a constructive dialog.

Cheers, Steve.

>  
>
>>>Another thing that would be emensely helpful is a suite of test
>>>cases for both ContainerKit and Merlin that prove their compatibility
>>>and their claims.  Merlin has absolutely no testcases which makes me
>>>nervous.  I haven't looked at the ContainerKit code, but if it has 
>>>the same problem it needs to be rectified.
>>>
>>>      
>>>
>>Merlin does not include formal test-cases at this time.  It 
>>does include several demonstrations and is constantly validated 
>>against a large number of components here on my machine.  Please 
>>feel free to jump in with test cases into the Merlin project - all 
>>contributions will be highly appreciated. In the meantime, my 
>>priorities are to make sure that Merlin is complete and well 
>>documeted before launching into the test-case preparation.
>>    
>>
>
>I've got other things to do.  Formal testcases are very important,
>and part of the proper validation of components and other pieces.
>One of the things I have to do is add more formal testcases for
>Fortress.
>
>  
>
-- 

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