directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: r106798 - /incubator/directory/eve/trunk/xdocs/building.xml /incubator/directory/eve/trunk/xdocs/components.xml
Date Sun, 28 Nov 2004 09:01:06 GMT
Author: akarasulu
Date: Sun Nov 28 01:01:05 2004
New Revision: 106798

URL: http://svn.apache.org/viewcvs?view=rev&rev=106798
Log:
More docs

Modified:
   incubator/directory/eve/trunk/xdocs/building.xml
   incubator/directory/eve/trunk/xdocs/components.xml

Modified: incubator/directory/eve/trunk/xdocs/building.xml
Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/building.xml?view=diff&rev=106798&p1=incubator/directory/eve/trunk/xdocs/building.xml&r1=106797&p2=incubator/directory/eve/trunk/xdocs/building.xml&r2=106798
==============================================================================
--- incubator/directory/eve/trunk/xdocs/building.xml	(original)
+++ incubator/directory/eve/trunk/xdocs/building.xml	Sun Nov 28 01:01:05 2004
@@ -53,5 +53,6 @@
         </tr>
       </table>
     </section>
+    
   </body>
 </document>

Modified: incubator/directory/eve/trunk/xdocs/components.xml
Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/components.xml?view=diff&rev=106798&p1=incubator/directory/eve/trunk/xdocs/components.xml&r1=106797&p2=incubator/directory/eve/trunk/xdocs/components.xml&r2=106798
==============================================================================
--- incubator/directory/eve/trunk/xdocs/components.xml	(original)
+++ incubator/directory/eve/trunk/xdocs/components.xml	Sun Nov 28 01:01:05 2004
@@ -2,16 +2,15 @@
 <document>
   <properties>
     <author email="akarasulu@apache.org">Alex Karasulu</author>
-    <title>Apache Directory Project: Components and Services</title>
+    <title>Eve Components</title>
   </properties>
   
   <body>
     <section name="Resources">
         <p>
           If the following sections sound a little cryptic you might want 
-          to read a little about the IoC pattern. There is no better place 
-          than Avalon for that.  Below are some Avalon documents you might find
-          useful when translating some of this babble:
+          to read a little about the IoC pattern. Below are some documents you
+          might find useful when translating some of this babble:
         </p>
         
         <ul>
@@ -39,34 +38,24 @@
       </p>
       
       <p>
-        A micro kernel or component container is required to run the server.
-        A micro kernel is a peice of code operating as a component container 
-        providing services for that component and running the component 
-        through a set of life-cycles.  Eve is designed to run on any micro 
-        kernel using component wrappers.  Her subsystems and components are 
-        designed as Plain Old Java Objects (POJOs) that can be wrapped to 
-        make them interoperate within different containers.  Eve is slated to 
-        work with both Merlin and PicoContainer, but there are no restrictions
-        to using containers like Loom, Plexus, or Phoenix.
+        A micro kernel or component container is required to run the server.  By
+        default the server uses its oun glue rather than a container with all the
+        bells and whistles.  However it can run in any micro kernel using
+        service wrappers.  A micro kernel is a peice of code operating as a
+        component container providing services for that component and running
+        the component through a set of life-cycles.  Eve is designed to run on
+        any micro kernel using component wrappers.  Her subsystems and
+        components are designed as Plain Old Java Interfaces and Objects (POJIs
+        and POJOs) that can be wrapped to make them interoperate within
+        different containers.
       </p>
       
       <p>
         Each component within Eve has a public service interface which 
-        declares what that component can do for its clients.  The service
-        interface is kept and packaged separately from any component 
-        implementation.  The separation is achieved by using a different maven
-        project hence build jar for the SPI and the implementations of that
-        service.  An SPI project is often used to contain the service 
-        interface and other interfaces associated with the component.  
-        Providers of the service must implement the interfaces in the SPI.
-      </p>
-      
-      <p>
-        The drive behind this approach has to do with modularity and 
-        classloader schemes.  It is always good to keep the interfaces 
-        separate from any specific implementations.  You can have many 
-        implementations for the same service interface.  Secondly the 
-        classloader heirarchy in containers often puts implementation
+        declares what that component can do for its clients.  It is always good
+        to keep the interfaces separate from any specific implementations.  You
+        can have many implementations for the same service interface.  Secondly
+        the classloader heirarchy in containers often puts implementation
         classloaders under a classloader containing the service interface. 
         This allows containers to manage multiple implementations for the
         same service without having conflicts.  Also implementations can be
@@ -78,20 +67,18 @@
     <section name="Container Independence">
       <p>
         One of the biggest impediments we've had to deal with while developing
-        Eve and some precursors was having containers go in and out of fashion.
+        Eve and its precursors was having containers go in and out of fashion.
         We lost several months of development time while switching from Pheonix
         to Merlin.
       </p>
       
       <p>
-        We believe we have a winner with Merlin but are not going to take 
-        anymore chances with container dependency.  The server is being 
-        designed from the ground up to be independent of any container.  We are
-        doing this by first making the default implementation of a service a 
-        Plain Old Java Object (POJO).  Wrapper implementation projects, one for 
-        each supported container, are used to wrap these POJO components to 
-        introduce container specific lifecycles and to encapsulate container 
-        idiosyncrasies.
+        The server has being designed this time from the ground up to be
+        independent of any container.  We are doing this by making the default
+        implementation of a service a Plain Old Java Object (POJO).  Wrapper
+        implementation projects, one for each supported container, are used to
+        wrap these POJO components to introduce container specific lifecycles
+        and to encapsulate container idiosyncrasies.
       </p>
       
       <p>
@@ -110,15 +97,15 @@
     
     <section name="Monitors Verse Loggers">
       <p>
-        Above we provided a link to Leo Sutic's concept of a Monitor.  Briefly
-        without restating his wiki we'd like to review how we use Monitors 
-        instead of Loggers alone.
+        Above we provided a link to Paul Hammant's concept of using Monitors
+        in place of Logging.  Briefly without restating his wiki we'd like to
+        review how we use Monitors instead of Loggers alone.
       </p>
       
       <p>
         Like any other server we need to log what goes on.  But rather than log
         we need to monitor.  Logging is a specific type of monitoring for the 
-        sake of archiving what we monitor.  Leo proposed that every service 
+        sake of archiving what we monitor.  Paul proposed that every service
         should propose a very specific Monitor interface.  This is a good idea 
         because it is the responsibility of the service to announce those 
         interesting, and monitoring worthy events.  The interface forces 
@@ -127,30 +114,17 @@
       </p>
       
       <p>
-        This allows us to add Monitor interfaces and adapter to an SPI to 
-        define the those interesting events for a component without the concept
-        of Logging at all.  This makes the component implementation logging
-        system independent which is provided by a container implementation.
-        Each wrapper implementation can provide its own Monitor implementation
+        This makes the component implementation logging system independent
+        which is provided by a container implementation.  Each wrapper
+        implementation can provide its own Monitor implementation
         to interface with the Logging system of the target container.
       </p>
       
       <p>
         We gain by becoming more container independent but more importantly we
-        are forced to consider what events in a service, NOT its component 
-        implementations, constitutes a noteworthy event.  This throught 
-        provoking aspect is perhaps the most beneficial.
-      </p>
-      
-      <p>
-        So what does this mean in terms of Avalon logging.  Well you'll see
-        wrapper projects targeting Avalon containers with an 
-        Avalon[Component]Monitor which implements the [Component]Monitor 
-        interface.  This monitor implementation is LogEnabled and it handles 
-        writing to logs as it encounters monitoring events for the component.
-        This monitor would be constructed by the wrapper at or after the 
-        LogEnabled lifecycle and used by the POJO which the Merlin component
-        delegates service calls to.
+        are forced to consider what events in a service constitutes a
+        noteworthy event.  This throught provoking aspect is perhaps the most
+        beneficial.
       </p>
     </section>
     
@@ -158,7 +132,7 @@
       <p>
         Containers are neat because they give component developers a lot of 
         nice features out of the box and that's what they should do.  The key
-        to maintaining container independency is to abstract away from these
+        to maintaining container independence is to abstract away from these
         features while still taking advantage of them.  This usually translates
         into a few extra interfaces and classes.
       </p>
@@ -176,35 +150,7 @@
         configuration beans.  POJO implementations are then designed to take 
         configuration beans as constructor arguments if the number of parameters
         is large and putting so many parameters into a constructor would be
-        too cumbersome.  This configuration bean can also go into the SPI and
-        has the effect of clarifying the configuration data types required.
-      </p>
-    </section>
-
-    <section name="Dependencies">
-      <p>
-        Within a component based system like Eve, services are interfaces 
-        implemented by components.  Component are implementations.  They
-        obviously depend on their service interfaces.  Hence all component
-        implementation projects including the POJO and container specific 
-        wrappers depend on the project containing the service provider 
-        interfaces or SPI.  Furthermore, every component wrapper besides 
-        depending on the SPI project will depend on the POJO component project
-        which it wraps for use in a target container.  The dependencies between
-        the projects of a service and its components are easily understood and
-        always exist. 
-      </p>
-      
-      <p>
-        Dependencies between components and service are not that simple.  It is
-        very important that developers understand the nature of inter component
-        and service dependencies.  Service interfaces by themselves do not and 
-        should not depend on anything other than perhaps APIs.  Components 
-        should be designed to depend on services and not components implementing
-        the service.  By doing so a component allows the implementation of 
-        dependent services to change without affecting its operation.  The 
-        contract is in the service interface.  Althought this is common 
-        knowledge to most we felt it important enough to reiterate just in case.
+        too cumbersome.
       </p>
     </section>
   </body>

Mime
View raw message