mcconnell 2002/07/21 00:02:07
Modified: assembly docs.xml
assembly/src/xdocs faq.xml
Log:
faq addition
Revision Changes Path
1.3 +2 -0 jakarta-avalon-excalibur/assembly/docs.xml
Index: docs.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/docs.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- docs.xml 21 Jul 2002 05:13:59 -0000 1.2
+++ docs.xml 21 Jul 2002 07:02:07 -0000 1.3
@@ -75,6 +75,8 @@
<target name="docs" depends="anakia-check" description="Generate
documentation and website">
+ <touch file="${xdocs.dir}/aaaa.xml"/>
+
<taskdef name="anakia"
classname="org.apache.velocity.anakia.AnakiaTask">
<classpath refid="tools.class.path"/>
1.2 +34 -2 jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- faq.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ faq.xml 21 Jul 2002 07:02:07 -0000 1.2
@@ -7,7 +7,37 @@
</properties>
<body>
<section name="Frequently Asked Questions">
- <p>In preparation.</p>
+ <subsection name="What's the difference between Merlin and Fortress?">
+
+<p>Merlin and Fortress are very similar in that they both address the
requirement for an embeddable component container. Merlin and Fortress differ
in terms of the requirements that they meet. Fortress focuses on the needs
related to frequent service activation requests based on service interface
request supplied by a client to a service or component manager. Merlin on the
other-hand is more concerned with complex service management systems
establishment.</p>
+
+<p>Fortress contains a more complete set of service/component manager in
terms of lifestyle handling than Merlin, however, the functionality inside
Fortress concerning formal dependency management and service assembly is
relatively weak. Relative to the Merlin architecture, Fortress can be
considered as a type of container. Looking forward, it would be desirable for
Merlin to be able to include Fortress as a type of container (i.e. have
Fortress implement the Merlin <a
href="api/assembly/org/apache/excalibur/merlin/container/Container.html">Container</a>
interface). This would expand the service lifestyle models available.
Another approach would be to merge the Fortress and Merlin developments,
however there are important issues relating to assumptions made at the level of
service/component manager lookup request and semantics related to
component/service selectors that remain open.</p>
+
+<p>User's familiar with the ECM framework will find may aspects of Fortress
familiar. User's that have experience problems related to larger scale
activation ordering, complex configuration, or context dependent components
will find Merlin more appropriate to their needs.</p>
+
+ </subsection>
+
+ <subsection name="What's the difference between Merlin and Phoenix?">
+
+<p>Merlin and Phoenix can be considered to be derived from the same family
in terms of architecture and notions of "what a component is". Both Merlin and
Phoenix leverage meta-information about a type of component (the .xinfo
resource). Meta information used by Phoenix is described as a <block>
whereas Merlin uses the more general <component-info> model. Both models
are relatively equivalent and it is expected that Phoenix will be migrating to
a common <component-info> schema in the near future. With this in place,
Phoenix based components will be usable within Merlin providing the compoennts
do not use Phoenix specific interfaces or classes. Typically, the two aspect
to watch for on Phoenix based components that limit portability are (a)
references to the class BlockContext (which can be eliminated by using the
context key instead of Phoenix specific context accessors), and (b), the usage
of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
+
+<p>Aside from these differences, Phoenix and Merlin are very similar - they
both handle service assembly, activation, and decommissioning. Differences
appear with respect to the approaches used and the overhead implied on a user.
Merlin makes every attempt to minimise that level of information required to
assemble a service model. For example, Merlin does not require explicit
linking of components under an assembly file. Furthermore, Merlin provides a
framework for defaults management enabling automatic service establishment.
Perhaps most significant is the design objective of Merlin to provide simple
programmatic embedding of kernels and containers into other components and
foreign systems. Relative to Merlin, Phoenix is much more static in that it
requires a significantly higher level of engagement in the establishment of a
service model. On the other-hand, Phoenix contains additional features not
present in Merlin - in particular JMX support.</p>
+
+<p>At the overall architecture level Phonenix provides support for pluggable
facilities (cut-down components) to provide support for core servises towards a
set of applications. Merlin's goes further by providing the ability for real
"component" based facilities model via embedded <a
href="api/assembly/org/apache/excalibur/merlin/kernel/Kernel.html">kernels</a>
that export services backed by a flexible hierarchical <a
href="api/assembly/org/apache/excalibur/merlin/container/Container.html">container</a>
structure. Based simply on available functionality, Phoenix, it's the choice
when selecting an app-server. Merlin on the other-hand demands substantially
less engagement by the end-user and delivers a commensurate reduction in
support overhead.</p>
+
+ </subsection>
+
+ <subsection name="What's the difference between Containerkit and the
Merlin Meta-Model?">
+<p>The meta model defined in both Containerkit and Merlin separates out the
notion of type related meta-info from the criteria for instantiation - commonly
referred to a meta-data. The containerkit and Merlin meta-info APIs are
basically equivalent, in fact both models currently share the same DTD for XML
based component type declarations.</p>
+
+<p>The Merlin API used more human friendly naming conventions (e.g. a type
is referred to a <a
href="api/meta/org/apache/excalibur/meta/info/Type.html">Type</a>, a component
profile at the meta-data level is called a <a
href="api/assembly/org/apache/excalibur/merlin/model/Profile.html">Profile</a>,
the association between profiles is called an <a
href="api/assembly/org/apache/excalibur/merlin/model/Association.html">Association</a>
- whereas containerkit references the same entries using more technically
oriented naming conventions - ComponentInfo, ComponentMetaData and
DependencyMetaData respectively). Aside from naming conventions, the Merlin
meta-info model includes a method through which a client can assess a default
configuration associated and packaged with the type.</p>
+
+<p>At the meta-data levels the differences are more significant.
Containerkit requires that the associations between produced and consumers are
declared at the time of meta-data creation (final constructor arguments). In
the Merlin model these assembly directives can be added progressively
(non-final variables). This reflects the divergence in the approaches to
assembly enabled in Merlin (dynamic) versus the (static) approach employed by
Phoenix.</p>
+
+<p>At a packaging level, the Merlin meta-data model is cleanly separated
from the meta-info model (separate jar files), enabling reuse of the meta-info
framework independently of container specific abstractions that occur in the
meta-data layer.</p>
+
+ </subsection>
+
</section>
</body>
<footer>
@@ -18,5 +48,7 @@
</footer>
</document>
+
+
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
