Return-Path: 
 <avalon-dev-return-10458-qmlist-jakarta-archive-avalon-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org
Received: (qmail 81390 invoked from network); 4 Jun 2002 21:20:33 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 4 Jun 2002 21:20:33 -0000
Received: (qmail 17509 invoked by uid 97); 4 Jun 2002 21:18:53 -0000
Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org
Received: (qmail 17459 invoked by uid 97); 4 Jun 2002 21:18:53 -0000
Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:avalon-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:avalon-dev-help@jakarta.apache.org>
List-Post: <mailto:avalon-dev@jakarta.apache.org>
List-Id: "Avalon Developers List" <avalon-dev.jakarta.apache.org>
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Delivered-To: mailing list avalon-dev@jakarta.apache.org
Received: (qmail 17423 invoked by uid 98); 4 Jun 2002 21:18:52 -0000
X-Antivirus: nagoya (v4198 created Apr 24 2002)
Message-ID: <3CFD1654.2060608@osm.net>
Date: Tue, 04 Jun 2002 21:34:44 +0200
From: Stephen McConnell <mcconnell@osm.net>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
 rv:1.0rc2) Gecko/20020510
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Avalon-Phoenix Developers List
 <avalon-phoenix-dev@jakarta.apache.org>, Avalon Developers List
 <avalon-dev@jakarta.apache.org>
Subject: Re: thinking Merlin/Pheoix stuff ...
References: <3CE6769A.3030403@osm.net> <200205311134.48785.donaldp@apache.org>
 <3CF72D70.1020005@osm.net> <200206011704.15446.peter@apache.org>
 <3CFA3188.3050202@osm.net> <3CFC9736.5030206@yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



Paul Hammant wrote:

> Stephen, Peter,
>
> I just wanted to say, that I've read the entire thread, but can't say 
> I completely understand what is being proposed and countered.  I know 
> that is not much help, but I think it right to illustrate that I've 
> not ignored this call for greater mindshare.
>

Hi Paul:

I'll try to recap things (and I'm also posting this to the general list 
because it is relevant to discussions concerning containers and general 
lifecycle management).

Both Merlin and Phoenix use information from a .xinfo file to determine 
the dependencies that a component has when building the container.  In 
addition to dependencies, both deal with the management of component 
configurations and component assembly.  However, Merlin and Phoenix 
diverge in the way configuration and assembly information is managed.

Merlin enables the introduction a release configuration as something 
separate from a deployment configuration.  The release configuration is 
static (only modified by a developer). The actual configuration instance 
supplied to a component is a composite of the release and the deployment 
configuration (via the CascadingConfiguration class) - so in effect the 
site configuration can supplement/override a release configuration.  
This makes it possible to supply components with pre-configured 
configuration which in many cases need no modification and in the worst 
case, maybe one or two declarations to customize a component for a 
particular site.  Merlin currently holds the release (default) 
configuration in the <classname>.xinfo file.  The current conclusion on 
this topic is that this could be moved to a <classname>.xconfig file and 
could be supported by both Merlin and Phoenix without problem.

The second area of assembly is more complicated.  Merlin was created 
with the specific objective of automatically running a target component 
without the need for explicit specification of assembly information.  
I.e. "take any component and just run it".  In simple cases this is 
possible based on the combination of dependency declarations and default 
configurations. However, problems arise when the target component (T) 
has a dependency on an assembled component (A) in that it must be able 
to declare in the dependency statement that (A) can provide (x).  In 
practical terms, an application (T) has a dependency on an ORB (A) from 
which it can get a time service (x).  The dependency declaration model 
we have only supports the declaration of the interface together with the 
role name.  What's missing is the ability to declare within a dependency 
a declaration that the supplied service must meet a particular minimum 
criteria to be considered as a viable service.  Merlin's approach here 
is to include a configuration fragment inside the dependency 
declaration.  During composition, that configuration fragment is added 
to the configuration chain that is build up when preparing the dependent 
component.   The Phoenix approach is similar except that it has a level 
of indirection ... the dependency declares a role, the assembly.xml 
declares the mapping to a particular component configuration.  The issue 
is that Merlin's inclusion of a configuration fragment inside a 
dependency declaration breaks compatibility with Phoenix. 

All of this comes does to the fact that we don't have a mechanisms to 
declare constraints within a dependency.  Role and interface are not 
sufficient - but introducing additional criteria needs to be considered 
carefully because this must be resolvable by any container dealing with 
any component.  In effect, we (the Avalon community) have been handling 
[micro] component assembly somewhat implicitly through configurations 
(as distinct from [macro] assembly based on dependencies).

Somehow, we need the ability to say the following:

  <dependencies>
     <dependency>

         <!-- declaration of a classic dependency -->

         <role>orb</role>
         <service name="org.apache.orb.ORB" version="2.4">

            <!--
            Plus something here that declares the minimum
            criteria that the supplied service must meet
            for it to be a satisfactory candidate.
            -->

            <assembly>

                <!--
                Anything in here is basically information
                that is specific to the dependent service.
                For example, in the case of an ORB this is
                typically a set of interceptor declarations
                that will result in the ORB composition with
                a set of resolvable extensions needed by
                this component.
                -->
 
                <initializer name="time"
                   class="org.apache.time.Initializer"/>
              
            </assembly>

         </service>

     </dependency>
 </dependencies>

Assuming that the <assembly> element was added as a valid child of a 
<service> element - what should Phoenix and Merlin do with it?.  The 
current Merlin approach is to include this fragment as a part of the 
configuration chain and everything works fine because it is up to the 
ORB component to interpret these directives.  On the other-hand, its not 
so easy to do this within Phoenix without the introduction of either an 
explicitly reserved element name in the configuration (undesirable), or, 
the introduction of an additional lifecycle phase that differentiates 
micro-assembly criteria from classic configuration content.

For example, consider the following:

   if( service instance of Composite )
   {
       try
       {
          ((Composite)service).assemble( criteria );
       }
       catch( CompositionException e )
       {
           // handle error
       }
   }

Such a phase would clearly come before initialization and probably 
follow configuration, however, I not completly convinced that this is a 
distinct phase (as opposed to a part of the process of initialization). 
If internal [micro] assembly is part of an initialization phase, then 
(a) the assembly constraint information must be supplied explicitly, or, 
(b) assembly criteria must be resolvable from the supplied 
configuration, or (c) assembly criteria must come in though the context 
information.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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