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! > 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." However you are marking them as helping the selection criterion be narrowed for a component and so forth? 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) 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. 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. > 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 . -- Cheers, Peter Donald "Artists can color the sky red because they know it's blue. Those of us who aren't artists must color things the way they really are or people might think we're stupid." -- Jules Feiffer -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
