mcconnell 2002/07/21 00:04:10
Modified: docs/merlin faq.html
Log:
faq
Revision Changes Path
1.2 +51 -3 jakarta-avalon-site/docs/merlin/faq.html
Index: faq.html
===================================================================
RCS file: /home/cvs/jakarta-avalon-site/docs/merlin/faq.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- faq.html 21 Jul 2002 04:57:41 -0000 1.1
+++ faq.html 21 Jul 2002 07:04:10 -0000 1.2
@@ -129,10 +129,58 @@
<td><div id="bodycol"><div class="app">
<div class="h3">
<h3><a name="Frequently Asked Questions">Frequently Asked
Questions</a></h3>
- <p
- > In preparation.
+ <div class="h4">
+ <h4><a name="What's the difference between Merlin and
Fortress?">What's the difference between Merlin and Fortress?</a></h4>
+ <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>
- </div>
+ <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>
+ </div>
+ <div class="h4">
+ <h4><a name="What's the difference between Merlin and
Phoenix?">What's the difference between Merlin and Phoenix?</a></h4>
+ <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>
+ </div>
+ <div class="h4">
+ <h4><a name="What's the difference between Containerkit and the
Merlin Meta-Model?">What's the difference between Containerkit and the Merlin
Meta-Model?</a></h4>
+ <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>
+ </div>
+ </div>
</div>
<div align="right" id="authors">
by <a href="[EMAIL PROTECTED]">Stephen McConnell</a>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
