avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [Newbie question] Confused (with correction)
Date Wed, 15 May 2002 19:03:27 GMT

Robert wrote:

>I wouldn't mind helping out here if I can(?). 

Superb - yes!!

>If I had the right info to add and the format, I would be 
>happy to help with the docs/website unless someone else has 
>already volunteered with that. Maybe I can bring
>that use perspective on it...

This sonds like a venture in the making !!

*  Leo has already put some new content together and knows
   the doc system

*  I'll start pulling together notes and recommendations and
   get it to the list.

*  if you can do some development in on the content Leo has
   already based on outlines/notes/comments ... that would
   be great (read this as a big understatement)

Cheers, Steve.

>Just a thought
>- Robert
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>Sent: Wednesday, May 15, 2002 12:39 PM
>To: Avalon Developers List
>Subject: Re: [Newbie question] Confused (with correction)
>Robert wrote:
>>I must say Stephen, this is the best description and comparison I've
>>ever seen on the various projects/apps. This should go on the website!
>I've been reading over the intro package for the Avalon website and 
>something struck me ... it doesn't actually say right up front what 
>Avalon is/does.  When I wrote the info you referenced - I had Leo in 
>mind as a potential 'target' and an underlying 'agenda' to instigate 
>some more direct messages on the web-site.  However - this is also a 
>terrible time for me to try to do anything too serious - just way - way 
>- way to busy on admin/business/finance stuff.  In an ideal world I 
>would like to kick around a bunch of things concerning the web-site but 
>it really difficult just at the moment - about all I can offer is 
>critique - and I'm not happy about doing that without a corresponding 
>contribution of something useful.  If someone has cycles available I can
>push out issues we need to deal with - I can provide good pointers to 
>what needs to chage (positives instead of negatives / make the techo 
>stuff move to background / focus on  the value proposition / define the 
>targets / define the products / define the services / clarify the Avalon
>brand / enforce the brand / etc ).
>Cheers, Steve.
>>- Robert
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>Sent: Tuesday, May 14, 2002 7:02 PM
>>To: Avalon Developers List
>>Subject: Re: [Newbie question] Confused (with correction)
>>Fredrik Hultin wrote:
>>>I have tried to figure how the different efforts under the Avalon
>>>umbrella are intended. But I am still not clear on why Phoenix
>>>use Excalibur's component manager or where Fortress fits into the
>>Taking a step back for a moment - here is a short description of the
>>five main areas within Avalon:
>>1. The Avalon framework - basically a set of building blocks for the
>>construction of component based solutions. Within the framework you
>>a set well-developed concepts that share a central notion of an object
>>lifecycle within the context of a development approached referred to as
>>Inversion of Control (IOC). Following IOC patters results in separation
>>the managing container from the component. In practice, the container
>>an implementation issue - but the components, their lifecycle and the
>>contracts they support are formally declared. That's why we see the
>>component details in framework and no formal definition of a container.
>>2. Excalibur is a collection of all sorts of things that leverage the
>>notions of IOC. Many of the packages in Excalibur use the framework as
>>construction toolkit. I tend to dip into Excalibur from time to time -
>>support for internationalization - some where to put framework
>>extensions - ideas concerning component management and containers, etc.
>>There are at least three different contains within Excalibur - the
>>original ECM (which reflects early work relative to the framework
>>abstractions) - Fortress (from my observation is something like
>>"son-of-Excalibur" - still evolving, but I believe a step forward in
>>thinking about formalizing utilities supporting creation od
>>There is Merlin which is a container that is more like a stripped-down
>>Phoenix with tweaks and go-fast additions like support for
>>ServiceManager, Serviceable, ServiceSelector.
>>3. Phoenix - this is a real serious container - basically a container
>>for running applications (as compared to Merlin, which is much more a
>>container for running components). Phoenix provides a lot more
>>functionality in respect to deployment flexibility - targeted towards
>>the deployment manager (as opposed to Merlin's focus towards a
>>4. LogKit - a logging implementation that respects IOC patterns
>>5. Applications - a bunch of very different application projects that
>>are capable of execution as packaged applications within the context of
>>the Phoenix platform
>>>Is the component manager deprecated and has Fortress taken over? Why
>>>then doesn't Phoenix use Fortress?
>>Keep in mind that ComponentManager and Fortess are really two different
>>things. ComponentManager is simply a utility used in one of several
>>phases in the management of component. It is not a manager of a
>>component - instead it is a utility through which a component can
>>the components it is dependent on. Recently the Avlon framework has
>>updated in include ServiceManager as a replacement with the intention
>>deprecating ComponentManager in the next release. ServiceManager and
>>ComponentManager are identical except that ServiceManager removes the
>>restriction of the Component marker interface (and therefore enables a
>>much broader scope of applications that can leverage the Avalon
>>framework and component model).
>>Fortress on the other-hand reflects a lot of the discussions that were
>>going on at the time of the introduction of ServiceManager and is
>>addressing the notion of a container. I would not class Fortess as
>>signed, sealed and delivered - but it is interesting content. Keep in
>>mind the point I mentioned above - containers are an implementation
>>concern - the components are an interface and formal semantics concern
>>so don't worry too much about which container is being used where -
>>because in an IOC world, components don't need to know about their
>>containers. As for Phoenix/Fortress - in my mind these are two
>>container approaches that are addressing two different scales of
>>component management. In addition, Phoenix is strong, reliable, and
>>validated - Fortress is still in hanger.
>>>What is the intent for the future? What projects will survive and
>>>will die in the near future?
>>We are seeing subtle and progressive elimination of marker interfaces -
>>for example, the replacement of Composable/ComponentManager with the
>>Serviceable/ServiceManager. This trend is also going on at the Phoenix
>>level where with luck we should soon be free of the Block marker
>>interface. In parallel, withdrawal of marker interfaces introduces
>>stronger dependencies on meta-information and I except we will see
>>development in that erea both in terms of tools supporting automatic
>>meta-info generation, and a convergence of approaches to component
>>related meta-management as various containers expose and validate best
>>practices in this area. In terms of what will die - I would recommend
>>avoid using the ComponentManager, and instead focus on tools and
>>utilities that leverage ServiceManager (but that statement is bound to
>>be controversial because lots of people are using ECM which has strong
>>Component/ComponentManager ties and ECM has not been upgraded to
>>the Serviceable/ServiceManger). Over on the Jakarta Avalon Apps group,
>>the Database, FTP server, HSQL, HTTP proxy, Overlord, Xcommand and the
>>Enterprise suite (ORB, Interoperable Naming Service, Persistent State
>>Service, Time Service ) are all component based applications with
>>suppport for Serviceable/ServiceManager semantics. Also, Phoenix offers
>>full support for the new Servicable/ServiceManager.
>>In addition to above, ECM has to deal with legacy issues concerning the
>>usage of the LogKit interface (as distinct from the abstract framework
>>Logger package) - which appears to be restricting its development to
>>some degree. My guess is that as Fortress matures will see more dialog
>>on this area - and in particular, discussion of ECM management and
>>evolution with respect to Fortress and the evolution of the framework.
>>Bottom line - the container isn't the issue - the critical aspects are
>>down in the framework. When emerges from Excalibur in the container
>>are just different approaches to similar problems they tend to reflect
>>different priorities. And finally, rolling your own container is also
>>totally valid - in fact in our internal applications we have several
>>"custom" containers that deal with families of components - and cases
>>where you just want to do something simply and directly. At the end of
>>the day our applications leverage custom containers (typically at a low
>>level), Merlin at the component level and Phoenix at the application
>>Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message