You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by mc...@apache.org on 2002/07/21 09:02:07 UTC
cvs commit: jakarta-avalon-excalibur/assembly/src/xdocs faq.xml
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>