avalon-dev mailing list archives

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

> I posted a "feeler" question to the PMC group today just to get some 
> initial feedback.  Considering the support from all parties, and the 
> concerns that I personally have, I would now like to get a bigger 
> picture of the whole Avalon developers group.
> I have a feeling that Avalon, and specifically Merlin is focusing 
> too much on the enterprise.  I know that the enterprise features 
> are necessary for some folks, but others simply do not need it.   
> It never really had simplicity, and to be honest I can't tell what 
> it does and does not do.  I know of a couple of people who are
> concerned (and will remain nameless until they choose not 
> to be).

I could talk about a couple of nameless multi-nationals that are 
building  commercial product on Avalon Framework, Avalon Utilities, 
Avalon Repository, and Avalon Merlin.  My point is that "nameless" 
individuals don't mean anything - just as my nameless multinationals 
don't mean anything.  What does matter are the opinions expressed 
publicly - for the benefit of the community and in the spirit of 

Moving on to more concrete topics ...

> 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?
  (b) why is Merlin scary?

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).

My guess is that your probably thinking about "how do I make Merlin 
internals do what I want" - and yes - that could be scary.  But the 
solution here is rather simple - take a step back and separate out the 

   (a) bootstrapping, this is all 100% avalon-repository stuff
       (same pattern could/should be applied to logging subsystem
       establishment, Fortress embedding, in fact any embedding
       scenario) - this means that the entry point is standard
       Factory model.

   (b) model creation, this is inside Merlin's DefaultFactory
       where a root system and a root application meta-model
       are created.

   (c) followed by creation of the runtime root system and
       application blocks that are handled based on supplied

 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.

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.

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.

> 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 

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.

> I am not really for a cease and desist type of action, but I really 
> want to know if my needs are truly that distinct from where Avalon 
> is going.  For a long time we have talked about something that would
> be easy to modify or easy to extend.

Start of with understanding what Merlin is (and isn't) and from there 
you will get an idea of which playground your in - either its 
parameterization of the platform to do things, or, your looking at 
platform customization.  If its the later - a little experience in using 
the platform will go a long way to understanding what the process is to 
introduce change (because its not just adding a configurable classname 
at line 122 - its about declaring the aspect formally in the meta model, 
expressing that aspect in the model readers and writers, and 
implementing the corresponding model level validation and runtime 

Yes, it sounds complicated but its the same process every time.

> 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.

> 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.

Concerning the embedded API (2), things are evolving and interfaces are 
chainging (but nothing radical and nothing that has caused a problem 
with people actually coding against this stuff).  In fact I think it is 
fair to say that the recent changes (3.0-2) have been a big plus for 
anyone working on a embedded container scenarios.  Yes, there will be 
evolution here - the work on the 3.4 branch (which has a lot of commit 
messages is dealing with refactoring of the assembly aspects - basically 
moving assembly logic from runtime layer to the model).  But 
irrespective of the fun and excitement under the 3.4, the actual commits 
related to 3.2 are almost all implementation enhancements (which is 
definely safe territory for change and evolution) which bring me to 
point (3).

Item (3) is and will remain open territory for change because Merlin 
(implementation) is about change, evolution, development, it about 
identifying what can be separated out, what is and is not a facility, 
what are the extensions points, what is the containment contract?  No 
apologies for hundreds of commits - they reflect interest and 
engagement.  Think of it this way - every commit is making Merlin 
smaller and smaller, less and less, and at the end of the day Avalon 
will have a rock solid containment architecture and reference 

> 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

2. identify what it is that you think that we all need

3. identify where that need plays into the Merlin platform - is is a
    system configuration question, is is a parameterizable aspect that
    needs to be exposed?

On completion of the above you have everything you need to in order to 
fulfill whatever it is the "we all need".

> 3) What about the guy with simple needs?  What are we going to do for him?

Merlin 3.0 is handling simple needs for hundred of users.

> 4) What about extensibility?  We need this if we are to survive.  Right 
> now I get the feeling that Merlin is an all or nothing approach.  Not
> a pick and choose the feature set approach.

 From Niclas' email to the PMC, he summarized extensibility features 
either in place or in progress:

   a. application deployment via repository system
   b. ability to select and alternative kernel on the command line
   c. ability to add custom facilities inside the kernel
   d. ability to add containment listeners
   e. customizable context handlers
   f. customizable lifecycle stage handlers
   g. ability to handle custom model implementations
   h. custom component instance factory
   i. custom deployment handler
   j. pluggable <element> handlers in meta info and meta data description
   k. customizable serialization factories
   l. customizable service factories (i.e. not just local components)
   m. embeddable codebase level security (on/off)
   n. pluggable subject level security

Items a-e are already in-place and the majority of the rest will 
probably make it within 3.4 with breaking the client component usage 

What this all means is that Merlin is progressively moving to a shell 
within which you put the features you need (via your components) - and 
you decide if you customizing the platform or the application.  But I 
need to restate the point that this is "a model-driven solution".

Cheers, Stephen.


| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |

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

View raw message