avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Component Metadata and Metainfo model
Date Fri, 05 Jul 2002 00:22:26 GMT


Leo Simons wrote:

>all,
>
>we have determined there is a need for a common object model to
>represent metadata and metainfo for avalon components. This to allow for
>portability of said components across containers.
>
>This object model has to be formalized in a way quite similar to the
>framework lifecycle, hence it is currently partially in the same
>excalibur module: containerkit.
>
>Definitions
>-----------
>metadata - basic definition: MetaData is everything that has to be
>provided to a component by its container in order for the component to
>function properly.
>
>metadata - avalon definition: MetaData is the assembly of object
>instances of a components declared dependencies on other components, as
>well as dependency on a Logger, Configuration, Parameters and Context.
>
>metainfo - basic definition: MetaInfo is a complete description of
>MetaData. Complete MetaInfo can be used to generate complete MetaData.
>
>metainfo - avalon definition: MetaInfo is an assembly of descriptors of
>a components declared dependencies on other components and on a Logger,
>Configuration, Parameters and Context, as well as a container for some
>human-readable information about the component.
>

Yep - I agree with the scope and defintions described above.

>
>note: metadata and metainfo is partly provided by java itself, primarily
>in the form of the Class method and related (ie Method). Additional
>standard metadata and info is provided in the form of descriptors first
>introduced with JavaBeans, where the information provided by Class is
>expended by providing an optional <<classname>>BeanInfo class. Other
>specifications like JMX expand on this (JMX has the option of providing
>a class extending MBeanInfo).
>
>current situation
>-----------------
>ECM is a bit of a mess wrt to metadata/metainfo. Phoenix allows
>specification of metadata through <<classname>>.xinfo files, as well as
>through xml configuration. Merlin partially allows the same
>configuration, and does some smart automatic determinition where an
>xinfo file is not provided.
>

Minor correction - Merlin does smart automatic determinition of the 
mapping of consumer and provider components without the requirment for 
explicit assembly directives.

>
>Suggested interfaces
>--------------------
>This builds upon the current avalon containerkit package. Please don't
>worry too much about namespace at this point.
>
>package org.apache.excalibur.meta;
>
>/**
> * The assembly of object instances of a components
> * declared dependencies on other components, as well as dependency on a
> * Logger, Configuration, Parameters and Context.
> */
>interface MetaData
>{
>	DependencyMetaData[] getDependencyData();
>	Logger getLogger();
>	Configuration getConfiguration();
>	Parameters getParameters();
>	Context getContext();
>}
>

I think we need to add the following operation:

	MetaInfo getInfo();

I.e. the association of a MetaData instance to its MetaInfo type or am I missing something?

>
>
>/**
> * MetaInfo is an assembly of descriptors of a components declared
> * dependencies on other components and on a Logger, Configuration,
> * Parameters and Context, as well as a container for some
> * human-readable information about the component.
> */
>interface MetaInfo
>{
>	ComponentDescriptor getDescription();
>	DependencyDescriptor[] getDependencies();
>	LoggerDescriptor getLogger();
>	ConfigurationDescriptor getConfiguration();
>	ParametersDescriptor getParameters();
>	ContextDescriptor getContext();
>}
>

Needs to include an accessor to the services descriptors provided by the 
component type.

    interface MetaInfo
    {
	ComponentDescriptor getDescription();
        ServiceDescriptor[] getServices();        //**
	DependencyDescriptor[] getDependencies();
	LoggerDescriptor getLogger();
	ConfigurationDescriptor getConfiguration();
	ParametersDescriptor getParameters();
	ContextDescriptor getContext();
    }

    interface ServiceDescriptor 
      extends FeatureDescriptor, ServiceDesignator
    {
    }

>
>
>/**
> * DependencyMetaData is the most complex part of the MetaData
> * specification. It maps the dependencies a component declares on
> * other components to a MetaInfo object.
> */
>interface DependencyMetaData
>{
>	MetaInfo[] getDependencies();
>	MetaInfo getDependency( String role );
>}
>

Dependency meta data should be declaring the associations of providers 
relative to a supplied role. I.e. you nedd to replace MetaInfo with 
MetaData in the above interface.

    interface DependencyMetaData
    {
	MetaData[] getDependencies();
	MetaData getDependency( String role );
    }

>
>
>/**
> * A descriptor provides a piece of MetaInfo about a component.
> */
>interface Descriptor
>{
>	/**
>	 * the common Descriptors (which extend this interface
>	 * provide stronger typed access to Descriptor attributes.
>	 * This method is here to allow for easier extension of
>	 * the MetaInfo.
>	 *
>	 * @returns the requested attribute, or null if the attribute
>	 * does not exist
>	 */
>	Object getAttribute( String key );
>	Object getAttribute( String key, Object defaultValue );
>
>	/**
>	 * Check whether the descriptor provides this attribute.
>	 *
>	 * @returns true if it does, false if it doesn't
>	 */
>	boolean containsAttribute( String key );
>}
>
>/**
> * provides valuable information to assembler and end user about a
> * component.
> */
>interface ComponentDescriptor extends Descriptor
>{
>	String getName();
>	Version getVersion();
>	String getDescription();
>	String getDefaultRoleName();
>}
>

I think the operation "String getDefaultRoleName();" is unclear.  The corresponding method
in the containerkit class isn't any better "String getImplemetationKey()". The problem is
that value returned from this operation is a key used by a container to access the implementation
class (the default value being the classname). This implies that a container must provide
a mapping from the key to a component resolver/factory if the value is a key - however - a
generic container cannot know if the value is a key or a classname.  Secondly - the absence
of an interface defining a factory/resolver means that it will not be possible for a generic
container to instantiate/resolve a component instance.

IMO it would be better to be explicit about this in the metainfo model by declaring a resolver/factory
classname that a key is evaluated against, and, specification of a resolver/factory interface
that a generic container can use.


>
>
>/**
> * Provide information about a component-to-component dependency
> */
>interface DependencyDescriptor extends Descriptor
>{
>	String getRole();
>	Version getVersion();
>
>	boolean isOptional();
>	boolean isRequired();
>	/* maybe...
>	DependencyDescriptor getAlternative();
>	boolean isAlternative( DependencyDescriptor descriptor );
>	boolean betterAlternativeTo( DependencyDescriptor descriptor );
>	*/
>}
>

Not favorable to the addition of alternatives (too much to do already 
with basic dependecies and the notion of optional depedencies) - less is 
better.  Also, the above interface is missing the defintion of the 
service interface.  Actually, the containerkit model of the seperation 
of the version and interface type into a seperate ServiceDesignator 
works well.

I.e.
 

    interface DependencyDescriptor extends Descriptor
    {
	String getRole();
        ServiceDesignator getService();
	boolean isOptional();
	boolean isRequired();
    }

    interface ServiceDesignator
    {
        Version getVersion();
        String getClassname();
        boolean matches( ServiceDesignator service );
    }

>
>
>interface ContextDescriptor extends Descriptor
>{
>	ContextEntryDescriptor[] getEntries();
>	ContextEntryDescriptor getEntry( String key );
>	String getType();
>}
>
>interface LoggerDescriptor extends Descriptor
>{ /* you get the picture now */ }
>
>interface ConfigurationDescriptor extends Descriptor
>{ /* this one, I dunno how to handle :/ */ }
>

I'm happy with the existance of the interface as this will allow 
seperation of the concern for future configuration constraints from the 
overall object model.

>
>
>interface ParametersDescriptor extends Descriptor
>{ /* you get the picture now */ }
>


>
>
>Wrapping up
>-----------
>Basically I think it is a good idea we hammer out some definitions,
>interfaces and contracts now. Part of why the discussion led to deadlock
>before is that it focussed on implementations, where it isn't that much
>of a problem if the implementation is container specific, as long as the
>container accepts any component with complete MetaData and MetaInfo.
>
>well?
>

This will certainly move things towards a more open framework - I like it.

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>


Mime
View raw message