Re: Blocks made of Blocks

Tue, 19 Aug 2003 22:20:24 -0700


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net

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




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to