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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
