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="[EMAIL PROTECTED]">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>
