avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcconn...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/assembly/src/xdocs faq.xml
Date Sun, 21 Jul 2002 07:02:07 GMT
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 &lt;block&gt; whereas Merlin uses the more general &lt;component-info&gt;
model.  Both models are relatively equivalent and it is expected that Phoenix will be migrating
to a common &lt;component-info&gt; 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:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message