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:[EMAIL PROTECTED]>
>>> For additional commands, e-mail:
>>> <mailto:[EMAIL PROTECTED]>
>>
>>
>> --
>>
>> Stephen J. McConnell
>>
>> OSM SARL
>> digital products for a global economy
>> mailto:[EMAIL PROTECTED]
>> http://www.osm.net
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
