avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Blocks made of Blocks
Date Tue, 19 Aug 2003 14:17:04 GMT

 From the Merlin composition tutorial.

Composition Management
======================

Overview
--------

This tutorial presents the creation ofn virtual components
using composition of package containers.  In this demonstration
we have three application groups, a top level application, a
locator system, and a publisher system.  The top level app
pulls in the two sub-systems as virtual components.  The sub-
systems are themselves fully deployable blocks in their
own right (although in this demonstratotion they represent
very simple sub-systems).  In practice, the combination of
packaged deployment profiles, default configurations,
auto discovery, auto assembly, and block composition provides
a powerful framework complex systems delivery.

Build and execution instructions:
---------------------------------

  $ maven build
  $ merlin application\impl\target\*.jar -system %MAVEN_HOME% -execute

  [INFO   ] (application.publisher.publisher): created
  [INFO   ] (application.location.info): location: Paris
  [INFO   ] (application.application): servicing application
  [INFO   ] (application.location.info): location: Paris
  [INFO   ] (application.publisher.publisher): created
  [INFO   ] (application.publisher.publisher):
  ******************
  * Paris
  ******************
  [INFO   ] (application.application): done


Use the following command to include container debug level log entries 
for the demanding developer.

  $ merlin application\impl\target\*.jar -system %MAVEN_HOME% -execute 
-config application\impl\conf\config.xml

Summary
-------

The purpose of this demonstration is to show how the container can be 
viewed as an implementation strategy for the creation of a virtual 
service, and how these service can be composed within a higher level 
containers, enabling new implementation solutions.  The key to achiving 
this is related to the <service> directives inside the <container> 
direective.  Each service directive describes a service that is exported 
by the container in its role as a virtual component.





Stephen McConnell wrote:

>
> Composite components from the Merlin point-of-view:
>
> 1. create a simple containment model:
>
>   <container name="simple">
>      <classloader>
>        <classpath>
>          <resource id="demo:simple-api" version="1.0"/>
>          <resource id="demo:simple-impl" version="1.0"/>
>        </classpath>
>      </classloader>
>      <component name="demo" class="Demo"/>
>      <!-- any other componenents or nested containers -->
>   </container>
>
> 2. create a composite component model that includes the simple model.
>
>   <container name="composite">
>      <classloader>
>        <classpath>
>          <resource id="demo:simple-api" version="1.0"/>
>          <resource id="demo:complex-api" version="1.0"/>
>          <resource id="demo:complex-impl" version="1.0"/>
>        </classpath>
>      </classloader>
>      <include id="demo:block" type="xml"
>      <component name="complex" class="AnotherComponent"/>
>      <!-- any other componenents or nested containers -->
>   </container>
>
> Note that the composite container inlcudes the API classes from 
> simple.  This ensures that the API content from simple is included in 
> the classloader that the composite container is running within.  
> Containers in Merlin look like components to other components and 
> participate as components during assembly.
>
> A practicle example of this approach to composition is included in the 
> james containment model within which there are about three level of 
> composition mainly dealing with the cornerstone components (some of 
> which are composite).  This also allows James to be exported as a 
> component and participate as a peer in higher level assembly and 
> deployment processes.
>
> CHeers, Steve.
>
>
> Niclas Hedhman wrote:
>
>> Hi,
>>
>> I am working on the higher-level concept of assembling existing 
>> components
>> into higher-level components and exposing that assembly as a new Block.
>>
>> There are several ways to do this, and I would appreciate any comments
>> from others who have looked into this.
>>
>> 1. A tool can map the outer-layer config into the config expected by the
>> inner-layer blocks, prior to packaging the SAR (for Phoenix). Vice 
>> versa,
>> it can rip out the inner-blocks assembly and transfer it to the SAR
>> assembly.xml prior to packaging.
>>
>> 2. The higher-level component can wrap a container inside and 
>> transfer the
>> outer-layer config to the inner-layers at runtime. The assembly of the
>> inner-layers are handled completely by the embedded container.
>>
>>
>> As for 1, I can manage to get this to work, but it seems like "the wrong
>> way".
>>
>> As for 2, I can not manage. Phoenix is out of the question as the 
>> embedded
>> container, and I don't know how to go about using Merlin as the embedded
>> container and Phoenix as the app container.
>>
>> Perhaps there are other alternatives.
>>
>> Shouldn't this whole issue be addressed by Avalon at its core?? If I 
>> can't
>> create components made of other components, we will never manage to 
>> build
>> very large re-usable system components.
>>
>> Niclas
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>> For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>>
>>  
>>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message