avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: jmx (RE: showcasing Avalon)
Date Fri, 30 Mar 2001 02:31:57 GMT


Harmeet Bedi [mailto:hbedi@yahoo.com] wrote:
[snip]
> I think Avalon is great. 

Me too!!

> It just needs to get into stabilization phase and
> brand building phase. I think individuals in different 
> companies would get it. My fear is that Avalon could get 
> too complicated.


I think this is a question of "brand management" .. here are 
the things that I have in mind when I look at the "Avalon 
big-picture"

	Phoenix 

         - a server activation framework - makes life easier 
           because I can use a "quasi-standard" model for 
           configuration of different blocks, deployment under 
           a .sar, etc.

	   - feels incomplete because of the lack of a management 
           interface (even a little local command line interface
           to start the server, reconfigure, stop, etc. would 
           complete the picture)

	   - biggest benefit is "potential" to re-use third-party
           blocks but (although this hasn't materialised yet)

	Avalon

	   - a set of interfaces that a project can use to improve 
           code quality and consistency .. its kind of like going 
           beyond coding practices and saying, ok, this is a set 
           of patterns that will be used on project X - based 
           on our experience that patterns work nicely (although 
           I think the Cascading exception model is insufficiently 
           exploited)

      Cornerstone

         - confusing, on one hand it looks like a set of 
           demonstrations on how to build a block, and the 
           demonstration were questionable a couple of months ago, 
           which lead to the assumption that "ok, that's nice, so 
           lets focus on the real things - Avalon core and Phoenix - 
           however, James used cornerstone components in a real context
	     which doesn't sit well with this theory - hence a little 
           confusion - maybe "demo" content should be slit out 
           away from real re-usable Cornerstone blocks?

Each of these packages target distinctly different in the types of users.  
In the Phoenix case its the server administrator and his problem is 
configuration, deployment, management, etc.  In the Avalon case the target 
is the "responsible" for project policy, coding standards, object model, 
etc.  In the Cornerstone case its the developer who wants to be able to 
re-use existing components - but the bottom line here is that these 
components are only as good as the documentation supplying the code as a 
fallback position does not cut it IMNSHO) - but before someone jumps on me 
for saying this, I have to confess that I haven't really check the javadoc 
on the cornerstone blocks in at least a couple of months - maybe things 
have been updated.

Conclusions .... 

   (1) move demo stuff out of Cornerstone if Cornerstone is 
       more than a demo

   (2) focus Phoenix "brand" as the runtime server deployment framework

	 - should be enhanced to handle ".sar"/".bar" declaration of the 
         version of Phoenix need for deployment (if you have
         any doubts about this, just try plying around with
	   Avalon CVS, Jakarta James, Jakarta Tomcat and the 
         eas.betaversion.org blocks :-)

   (3) focus Avalon on best-of-breed software practice

Cheers, Steve.







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


Mime
View raw message