Date: 2004-01-09T11:21:41 Editor: 160.33.82.119 <> Wiki: Apache Avalon Wiki Page: WhichContainer URL: http://wiki.apache.org/avalon/WhichContainer
no comment Change Log: ------------------------------------------------------------------------------ @@ -1,31 +1,22 @@ -= ECM, Phoenix, Fortress, Merlin, ... Which One? = -The Story of the Avalon Containers += The Title = -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. +A common question amongst new Avalon users is "Which container should I use?" or "What's the difference between Fortress, Phoenix, and Merlin?" This section of the wiki has been set aside to help answer these questions. For a more verbose history of where the containers came from, see the ContainerStory. -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. +== Short Introduction to Each Container == -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: +== Meta-Info and Meta-Data == - Component componentManager.lookup(String role); +'''Container Meta-Info Matrix''' (standard are critical) - 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. + ||Container ||Meta-Info Strategy|| + ||Phoenix || Container specific <blockinfo> descriptors. Contains information about service publication and service dependencies. || + ||Merlin ||Uses the standard Avalon Meta package. Avalon Meta descriptors expose information about service publication, runtime dependencies, context dependencies, deployment dependencies, deployment extension support, and a framework for general attribute association. || + ||ECM ||Uses marker interfaces to derive meta-info.|| + ||Fortress ||Uses a combination of marker interfaces and a service to component mapping table.|| +'''Container Meta-Data Matrix''' (solutions reflect container features) + || Container || Meta-Data Strategy || + || Phoenix || Maintains a list of components under a config file which are assembled based on a static mapping declared under an assembly file. System configuration is archived through a facilities file.|| + || Merlin || Meta data for the kernel definition is contained under a kernel configuration (kernel.xml) which defines internal facilities defined under a system block. Component meta-data used for internal facilities and application components are described in a block directive. A block directives may contain component and container declarations, and include other from local or remote locations. Block directives may be configured to simulate components. || + || ECM || Uses roles files to map names to configurations. || + || Fortress || Uses roles files to map names to configurations and provides support for container level configuration. || --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
