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