avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Where do you want to go?
Date Tue, 06 Jan 2004 15:03:03 GMT
Stephen McConnell wrote:

> 
>> To be honest, I am not in a situation where I need enterprise level 
>> architecture anymore.  I just need something simple.
>> The current Fortress does fit my needs, and I am almost scared to try 
>> Merlin. 
> 
> 
> There are two important questions here:
> 
>  (a) why does Fortress not meet your needs?

Fortress *does* meet my needs, but needs some work which I wish I had time
to do.  It needs community support.

>  (b) why is Merlin scary?

The code and dependency list look almost like a spider's web to me.  It's
not as clean and simple as the basic Fortress concepts.

> I can can speculate about the first, but I don't understand about the 
> second.  Feedback I'm getting is that Merlin is *really* easy to use - 
> in fact more than a few people have commented that it is the easiest 
> container they have used (within and external to Avalon).

Easy to use and easy to develop the internals are two different things.
How to add new arbitrary features that don't necessarily fall into the
Lifecycle extensions can seem to break things that I personally don't need
but others do.

>  From here you should stop looking at the code and start looking at the 
> composition package.  The entire package is about parameterization of 
> what happens at runtime.  If you cannot change something though the meta 
> model API than its not changeable.

To be honest, I find the inflexibility of the meta model to be a problem.
I like the work that Leo did for the arbitrary attributes that had real
objects with it.  It even addressed dynamically finding classes that implemented
the attribtues.

> 
> For example, Leo wants to switch in handling of Type 3 components. Well, 
> based on the meta-model contract as it stands, he can't because this 
> isn't an exposed parameterizable aspect under version 3.2.

But why can't it be?  What's wrong with the factory/instance management
separation in Fortress?  Can't that be directly supported in Merlin without
breaking contracts?  Then all that is needed is to add a new factory.

> What I'm saying is - focus on understanding the meta-model defined by 
> the composition package and from that everything falls into place. 
> Remember, its not code driven, it model driven.

Grmbl.  I think this is too much magic for the simple case.  For instance,
I may have some simple component needs where magic is the last thing on
the list, but in Merlin it can't be gotten around.

>> To be fair, I should declare what I mean by simple.  By simple,
>> I mean that I have a set of components I need, but I don't need 
>> security, proxying, etc.  Granted, I do need to extend the lifecycle, 
>> but that is another topic entirely.
> 
> This may not make a lot of sense but the feature profile your looking 
> for will probably arrive with Merlin 3.4 - i.e. scaling to "not much". 
> As Merlin moves forward it becomes less and less and enabling more and 
> more.
> 
> I.e. you have more choice in terms of what is is you want your container 
> to be.  On my machine here I have a full HTTP server running inside the 
> Merlin kernel (i.e. under the internal system SPI classloader) and 
> capable of monitoring and interacting with the entire meta-model.  I am 
> probably a few full on developer days away from having component == 
> servlet with the http server directing request to the component instance.
> 
> But what is import here is that this is not feature extension - its just 
> a component that happens to be running internally (it could be a logging 
> system, a JMX server, a JMS adapter, an ORB, whatever).  In fact the 
> entire HTTP stuff is two lines of XML inside the kernel.xml (one for the 
> server and one for the model listener).  The more this sort of internal 
> facility handling evolves, the smaller Merlin gets.

So what concerns are interwoven into Merlin that cannot be separated out?

>> Many of us can prove that it can be done--but noone is interested in a 
>> complete rebuild or new work.  I don't blame them. I feel the need for 
>> simplicity is being drowned out by the need for features.
> 
> I strong disagree with you on this point.  If you take a look at the 
> requirements from the James project - they need additional features but 
> this is translated into activities related to pluggable feature 
> handling. The same is true for the requirements coming from Turbine, the 
> OpenIM project, and other external projects.
> 
> Instead of looking at solving all of these feature enhancement requests 
> - the approach is to (a) refactor aspect of the kernel or meta model to 
> better handle custom solution requirements, and (b) where necessary, 
> expose an appropriate parameterization point in the meta-model.

How about using a flexible meta-model, and not worrying about predefined
extension points.  A plugin or feature package can use the new attributes
without having to perform code changes to the meta model.

>> Another thing that scares me is the rate of mutation for Merlin.  You 
>> may know what it does this week, but come back to it a couple weeks
>> later and everything is different.  There are hundreds of commit 
>> messages that go by all the time, and it is difficult for me to try to 
>> keep up with what is really going on.
> 
> On the Merlin system there are three separate considerations with 
> respect to change:
> 
>   1. changes to the XML type and block contract
>   2. changes to the kernel and model API
>   3. changes to the model and runtime implementation
> 
> As far as (1) is concerned - Merlin has remained rock-solid in support 
> for the component meta-data and meta-info contracts.

THat's good.

> 
>> The questions I have are this (for those who have not seen this earlier):
>>
>> 1) Am I alone in my concerns?
> 
> No, but I don't share the same concerns.
> I more aligned with Hammets comment ...
> 
>   >> My only "critic" to merlin is a better isolation of features, after
>   >> that it will rule the world.
> 
> And feature isolation is being addressed under the 3.4 branch.  In fact 
> there is a real possibility that the entire assembly package will become 
> a plug replaceable extension - leaving only composition and merlin core 
> as the "real" system facilities.  Again, I cannot emphasis enough, spend 
> some time looking at the composition package, understand the meta model, 
> then start exploring.
> 
>> 2) If not, how should we start refactoring Merlin to make it what we 
>> all need?
>>    * please note that development should be able to continue while 
>> refactoring
>>      occurs.
> 
> 
> 1. understand what exists and the architecture of the system

Very daunting

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message