Peter Donald wrote:
> On Wed, 4 Sep 2002 00:26, Berin Loritsch wrote:
>
>>I was thinking about Peter's proposal of making "Service" a full
>>featured
>>meta type, as well as implementing a meta data enabled container. I
>>know
>>both Phoenix and Merlin work with meta data, but I am starting my own
>>version (i.e. making Fortress act more Phoenix/Merlin-like).
>
> Woohoo!
:-D
>>What I like about making services and components full meta types is
>>summed
>>up in two aspects: Service resolution and Service management interface
>>publication. We had talked in the past regarding attributes helping the
>>container distinguish between multiple service implementations. However
>>there was no real way to validate the attributes, or use them in an
>>automated fashion. Here is what a service definition would allow us
>>to do:
>
> I attributes slightly differently but I have similarly come up against the
> limitations (lack of validation/definition).
>
> Anyways I tend to think of attributes as aspects rather than features of a
> artefact. So I tend to think in terms of saying things like "Apply these
> (persistence|transaction|remoting|security|instrumentation) attributes to the
> method/interface/component etc."
It's quite easy for to look at these as the old marker interfaces.
> However you are marking them as helping the
> selection criterion be narrowed for a component and so forth?
Hmmm, this is more like the component describing himself rather than
asking how to be treated...
> For an example I have attached the set of attributes I have attempted to boil
> down that are essentially container independent. The list used to contain
> many more but I have moved them to different categories;
> * toolkit specific (ie altrmi:*)
> * container specific (ie phoenix:*)
> * aspect specific (mx:*, persist:*) (Though I have barely looked at this side
> of things)
It seems like:
* toolkit specific => peer hints
* toolkit specific => parent hints
* aspect specific => new avalon framework marker interfaces (general
aspects)
> Anyway take a look at the list to see what I mean.
>
> However the validation is a common concern. I like your type list and think it
> should be extended to include things like regex matching. One thing I would
> like to follow is the way the IETF and OpenGL AB do standardization with this
> sort of thing. ie the values for an attribute may be an enum A, B and C. But
> if the component/container implements extension X then the set of allowable
> values may increase to be A, B, C and D.
>
> Other things you should consider when defining attributes;
> 1. the inheritance rules. ie Is the attribute inherited and if so what extent
> does the inheritance apply to. I think MS does either no inheritance, direct
> decendenc inheritance or full inheritance. (though I believe they can be
> overidden at deeper nodes in inheritance tree)
> 2. the default values for attributes
> 3. the relationships between attributes. (ie remote:enable = true implies
> either avalon:pass-by-value = true or remote:reference = true).
>
> (3) may be pie in the sky but other "attribute" based systems do support it to
> some degree. So it is worth thinking about.
>
> Anyways I would love to see a definition file, the simpler the better though.
Yup.
> One thing though, I am not sure that
>
>
>><service type="ConnectionManager" version="3.0">
>> <attribute-defs>
>> <attribute-def name="connection:secure" type="boolean"/>
>> <attribute-def name="connection:min-bits-encryption"
>> type="integer"
>> weighting="higher"/>
>> <attribute-def name="connection:codec"
>> type="enumeration"
>> case="insensitive"
>> policy="inclusive">
>> <value default="true">TRIPLE DES/SHA-1</value>
>> <value>FIPS 140-1</value>
>> <value>RC4</value>
>> </attribute-def>
>> </attribute-defs>
>></service>
>
> service interfaces should be the ones to define attributes. I think definition
> of attributes is an independent concern of service interfaces.
And here lies the point.
If we define "interfaces" and "metadata" both in an xml meta language,
we can use that between languages.
>>I'd like to get everyone's oppinion on this. I think it would be
>>beneficial
>>for us to be able to gather all the service descriptors, and validate
>>them
>>before we go through and gather all the component descriptors that refer
>>to
>>those services. That way we can validate the components against a set
>>of
>>preloaded services.
>
> I like that .
Me too :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
