Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <3FB020D9.8000105@apache.org>
Date: Tue, 11 Nov 2003 00:35:53 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Avalon Developers List <dev@avalon.apache.org>
Subject: Re: [Merlin] Service vs. Component
References: <3362F47D2574474E809FAA631BE43AD30D8B60@daedalus.kenamea.com>
In-Reply-To: <3362F47D2574474E809FAA631BE43AD30D8B60@daedalus.kenamea.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


Steve Harris wrote:

>I'm working on a document for a round table discussion we will be having
>about Merlin. I will probably have a few questions as I work on it and
>may even post it to get feedback if people don't mind. My first question
>is pretty simple. 
>
>Is it true that Components are no more in the merlin world? Do we strickly speak of Services now?
>

The "Component" (with a capital C) is an interface that was used in 
pre-history to mark a class as an Avalon component. The framework 
included a number of interfaces, notably Composable and ComponentManager 
that forced component implementation to implement the Component 
interface. However, the Component interface does not expose any methods 
- it was simply a marker.

During the middle-ages the notion of meta-info was developed primarily 
under the Phoenix container. This lead to a number of initiative to 
resolve a meta-info model that would be sufficient to fully express 
information about a component. During this time the restriction imposed 
by the Component interface were become more and more apparent when 
dealing with components such as CORBA objects that by specification 
cannot ans should not be implementing the Component interface.

An alternative to the org.apache.avalon.framework.component package was 
developed - and named org.aapche.avalon.framework.service. That package 
enables any object class to to be handled as a component - representing 
a major step forward for Avalon. More recently the full potential is 
shinning though with the combination of the service package (i.e. the 
equivalent of the component package without the artificial restrictions) 
with the avalon-meta package. The Avalon Meta package opens up much more 
flexibility concerning the description of a components operation 
criteria � information that a container needs to know in order to deploy 
the component. This meta-info is described in files associated with a 
component class and is referred to as a Type (component type descriptor).

http://avalon.apache.org/meta/meta/info/type/index.html

We still speak of components but is much lowercase these days. A 
component type may provide 0..n services and may consume 0..n services 
(and a bunch of other stuff). This notion has not changed - all we have 
done is remove the capitalization, opened Avalon to a much broader 
spectrum of application areas, and introduced a formal model for 
description of criteria.

Now onto Merlin (which built above all of this good stuff). Merlin is 
concerned with the deployment of component types in the context of 
information containing configuration details, context, parameters, etc. 
This infomation is referred to a meta-data. You will see lots of 
examples of <component .../> in the Merlin tutorials. The actual 
description of what <component/> can contain is defined here:

http://avalon.apache.org/merlin/meta/block/components/index.html

Merlin uses the combination of meta-info (description of a component 
type) and meta-data (descriptions of deployment scenarios) to build 
composite components automatically. This process of composition is 
founded an the ability to wire together the "services" produced by a 
"component" with "services" consumed by other components. I.e. service 
and component are alive and well (just no longer capatalized).

Cheers, Steve.


>
>  
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>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


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