You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2004/11/28 10:01:06 UTC
svn commit: r106798 - /incubator/directory/eve/trunk/xdocs/building.xml /incubator/directory/eve/trunk/xdocs/components.xml
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>