[Apache Avalon Wiki] New: WhichContainer

[si...@avalon.apache.org]

   Date: 2004-01-09T10:00:03
   Editor: 160.33.82.119 <>
   Wiki: Apache Avalon Wiki
   Page: WhichContainer
   URL: http://wiki.apache.org/avalon/WhichContainer

   no comment

New Page:

= ECM, Phoenix, Fortress, Merlin, ... Which One? =
The Story of the Avalon Containers

A common question of users new to Avalon is, "Which container should I use?" or "What's the difference between ECM, Phoenix, Fortress, and/or Merlin?"  These are good questions and the answers can sometimes be a little complicated.  

In the beginning there were only components.  The components had a role defined by a java interface and an implementation defined by a concrete java class.  In ECM and Fortress roles and components could be described in a set of XML configuration files, generally one for the roles and one for the implementations.  In Phoenix land, roles were still roles and components were still components, but they were defined in xinfo files scattered across the various jar archives that would make up an application.  This was done to allow developers to deploy a jar file that contained not only the interfaces and implementations, but also the basic meta-data.  Thus, the xinfo files and the conf files had the same purpose but were used by different containers.

At this time, all components were children of the one org.apache.framework.component.Component interface.  A brave developer scaled Mt. Doom and tossed the Component interface and all the other marker interfaces into the fiery pit, thus freeing all components from bondage of the one Component. 
 
Upon return from this quest, the developer said, "All Components shall now be dubbed Services" and a new set of ServiceManagers and ServiceSelectors appeared that could converse with any Object, not just Components.  These Service utilities performed the exact same functions as their deprecated Component counterparts, but didn't require everything be a Component.  That is:

    Component componentManager.lookup(String role);

  became
   
    Object serviceManager.lookup(String role);

So in this sense, Components ARE Services.  But now the Avalon community had two names for the same thing and this is generally were confusion arises.

Secondly, each container (currently) uses its own meta-data format.

  Phoenix = .xinfo file + block level assembly files
  Merlin  = .xinfo, .xtype + block level "block.xml" files
  ECM     = single XML file for all roles,
            single XML file for all implementations
  Fortress = can use ECM style configuration
             also uses simple 'meta-data' format with a services list
             that lives in the META-INF directory of a jar file

In each case, the same basic information is being stored:  what are the services, what are the implementations, what are their lifestyles, do they have any specific configuration information.  The dream is to eventually have everything use just one meta-data format (probably the Merlin version) but still have backwards compatibility for legacy apps.


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