avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: ContainerKits Meta data/info
Date Fri, 07 Jun 2002 00:21:24 GMT


Peter Donald wrote:

> Hi,
>
> I think you are confusing my intentions about attrributes. They are 
> purely an escape mechanism for container specific information.
>
> * Attributes on services do not necessarily denote extra capabilities.
> * Attributes on dependencies do not necessarily denote constraints.
>
> The attributes are purely directives to container for container 
> specific features. For instance you could mark a service as capable of 
> being "remoteable" which would mean you could export it via 
> WebService, CORBA, AltRMI etc.
>
> We may eventually create a standard set of meta-tags but until such a 
> time they are completely container dependent. The "availability" 
> attribute in batman may mean something completely and utterly 
> different from gotham-citys use of "availability" 


I agree - I cut-and-pasted the example from another email I havn't sent 
that was preparing question about exactly the point you talking about - 
what do attributes mean to the different actors involved.  The email 
hasn't been sent because I havn't figured out yet what the corresponding 
scenario is between the Merlin assembly delcarations, component 
attributes, service attributes and dependecy attributes.  However, there 
is a question I raised in that email thats independent of that issue - 
namely the redundancy of attributes on the service descriptor contained 
by a depedebncy declaration - I think the definition should be revised 
to something like a service reference.

Cheers, Steve.


>
>
>
> At 01:10 AM 6/7/2002 +0200, you wrote:
>
>> A couple of questions concering DependencyDescriptor and 
>> ServiceDescriptor:
>>
>> 1. If I have a component declaration such as:
>>
>>   <block>
>>     <name>batman</name>
>>     <version>12.0</version>
>>     <attributes>
>>       <attribute name="alias" value="Bruce Wayne"/>
>>     </attributes>
>>   </block>
>>
>>   <services>
>>     <service name="org.apache.TruthAndJustice" version="2.3">
>>        <attribute name="availablilty" value="7x8"/>
>>     </service>
>>   </service>
>>
>>   and a second component that is dependent on the above component:
>>
>>   <block>
>>     <name>gotham-city</name>
>>     <version>1.5</version>
>>   </block>
>>
>>   <dependecies>
>>     <dependecy>
>>        <role>superhero</role>
>>        <service name="org.apache.TruthAndJustice" version="2.3"/>
>>        <constraints>
>>          <constraint name="availablilty" value="7x24"/>
>>        </constraints>
>>     </dependecy>
>>   </dependecies>
>>
>>   The service declaration under the dependency is actually a service
>>   reference in that it does not make any sense for this to include
>>   attribute declarations. Would it not be better to sperate a
>>   service descriptor reference from the actual descriptor?
>>
>>   E.g.:
>>
>>      ServiceReference { String m_name, Version m_version }
>>          ^
>>          | [extends]
>>          |
>>      ServiceDescriptor { Properties m_attributes }
>>
>>   And from this, DependecyDescriptor could be more correctly defined as
>>
>>      DependencyDescriptor { String m_role, ServiceReference m_service,
>>         Properties m_constraints }
>>
>> 2. The second thing that pops up is the method name getAttribute in
>>   DependecyDescriptor - I think this should be renamed to getConstraint.
>>
>> 3. ServiceDescriptor is declared as a final class - is this necessary?
>>   In particular I would need to extend this to handle extraction of
>>   declared properties.
>>
>> Cheers, Steve.
>>
>>
>>
>> Peter Donald wrote:
>>
>>> Hi,
>>>
>>> I have just completed the first draft of the MetaData and MetaInfo 
>>> objects for container writers. I would appreciate if all you 
>>> container writers (particularly Berin, Leo and Stephen) would look 
>>> at the classes in
>>>
>>> org.apache.excalibur.containerkit.metadata
>>> org.apache.excalibur.containerkit.metainfo
>>>
>>> The metainfo classes are meta information about the component type. 
>>> Basically it contains information such as
>>> * what services does component support
>>> * what services does component require to operate
>>> * generic information (like classname of component and version of 
>>> component)
>>>
>>> The metadata contains basic information about a "assembled" 
>>> component. Basically it is the mapping of component dependencies. ie 
>>> Component A provides service P to Component B
>>>
>>> The metainfo should be sufficient to model all our containers. When 
>>> a container requires specific capabilities (ie Merlins constraints 
>>> or Fortresses lifestyles) it can use "attributes". Attributes are 
>>> basically opaque strings that describe container specific things 
>>> (See javadocs of the classes). The metainfo classes should not need 
>>> to be subclassed.
>>>
>>> In the future metainfo will probably include things like;
>>> * configuration/parameters schema (maybe XML Schema?)
>>> * required context values (Basically like resource-ref from J2EE world)
>>>
>>> The metadata package will probably need to be subclassed to provide 
>>> container specific information but it is a start.
>>>
>>> So what do you think? Is there anything else that it needs to 
>>> support for it to be useful in all containers?
>>>
>>>
>>> -- 
>>> To unsubscribe, e-mail:
>>> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>>> For additional commands, e-mail: 
>>> <mailto:avalon-dev-help@jakarta.apache.org>
>>
>>
>> -- 
>>
>> 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>
>
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>
>

-- 

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