> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> 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!
I thought you would like that. I had to let the dust settle before
I started though. I believe we are at a place where I can use either
the Meta package or COntainerKit and still come up with a compatible
definition. That is good--considering the fact that Fortress will be
using the experimental Extensions as well (since they originated from
Fortress).
> > 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.
But aren't most of these attributes belonging to an implementation?
Let's say we have two implementations of a Scheduler--one that is
completely local, and one that is able to be remoted. The "remoting"
attribute belongs to the implementation not the interface.
Same with "instrumentation"--not all implmentations of a service (aka
work interface) will be instrumented.
Component level attributes are very important. Another aspect that
is important is marking an interface publishable as a management
interface. A "management" interface means that it belongs to a
management component, therefore all implementations must be able to
be exposed as a management point.
Things like "mx:*" (management specific) would be welcome in the
Service interface, However all the other aspects you listed would
be component implementation sepecific.
> 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.
It's a starting point. Now, with the enumeration type, I had
two modifiers: "inclusive" and "exclusive". If the list was
"exclusive", it would exclude any other possibility that was
not defined in the interface. If it was marked "inclusive",
most likely the default, then a component would be able to
list a value not on the enumerated list.
> 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)
Selection criteria attributes are not inherited. Each Service
interface is completely different, therefore each Service descriptor
is completely separate. We have run into some serious issues
with inheritance and Cocoon.
A typical example that occurred is that someone defines an abstract
base type for a component which extends a lifestyle interface like
Poolable. Further down the inheritance tree, someone wants to extend
a different lifestyle interface like SingleThreaded. The container
gets confused and throws the component out because it is misdefined.
If a service interface extends another service interface--essentially
creating a new type, the original attribute constraints do not
necessarily
apply to the new type. So in regards to the SERVICE, no inheritance
would be the best policy.
> 2. the default values for attributes
The attribute-defs that I listed included default values and default
interpretation strategies. For instance, the enumeration required
at least one of the value entries to be marked default="true". The
numbers always default to 0, and the default interpretation is higher
numbers are preferred to lower numbers. Booleans are defaulted to
false. If we support generic strings they would be defaulted to
an empty string--however they are not a good type to select against,
which is why I used the enumeration strategy instead.
> 3. the relationships between attributes. (ie remote:enable =
> true implies
> either avalon:pass-by-value = true or remote:reference = true).
How about remote:enable = avalon:pass-by-value ?
That seems clear that both of those mean remote:enable = true and
avalon:pass-by-value = true.
To disable it (which is default anyway), we would do something like
remote:enable = false .
> (3) may be pie in the sky but other "attribute" based systems
> do support it to
> some degree. So it is worth thinking about.
Relationships between attributes have to be well defined in advance.
The important thing with all the attribute types that you are referring
to here is that it is impossible for a small container to support
all of them. Therefore, attributes have to be viewed as things to
support if you are able, but the system will still work if you can't
support them.
For example:
It is unlikely that the supplied Fortress containers will be *able* to
support the "remoting" attribute. The system cannot fail just because
Fortress cannot support that attribute.
The thing that makes me wonder though is whether those attributes would
be able to be supported by the extensions mechanism defined by Fortress
and Merlin. If so, that would be a nice way of handling the optional
attributes, and defining attribute dependencies.
In the mean time, I want to focus on the simpler aspect of component
resolution. I have that in my head, while I am still mulling over the
other attributes.
> 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.
The service interface that defines attributes (i.e. attribute-defs)
would be required to allow a container to choose the best component
implementation for the job automagically. Therefore, the only
attributes defined at this level are the ones that the container
would use to validate and use to select between component definitions.
In essence, for most applications we can get started right away,
without an assembly descriptor. The container can then serialize the
assembly descriptor, and allow the maintainer of the system to override
its choices. The biggest thing is that most likely Merlin, Fortress,
and Phoenix will all have different assembly markups. Instead of
requiring the user to know each of the assembly markups, or causing
endless fighting over which one is best, we simply create it
automatically.
In order for that to happen, we need to know which attributes have
meaning to the service interface, and how to interpret those attributes.
The component implementation itself *declares* the attributes that the
specific implementation supports, so that we can choose the
implementation
based on a required spec. That way inside the type definition
(blockinfo)
we would declare something like this:
<dependencies>
<dependency optional="false">
<role>connections</role>
<reference
type="org.apache.cornerstone.services.connection.ConnectionManager"
version="3.0"/>
<attributes>
<attribute name="connection:secure" value="true"/>
<attribute name="connection:min-bits-encryption" value="128"/>
</attribtues>
</dependency>
</dependencies>
Perhaps we need a "depends" attribute so that we can mark certain
attributes
as having significance only when another is used. Something like this:
<attribute-def name="connection:min-bits-encryption"
type="integer"
weighting="higher">
<dependency attr="connection:secure" value="true"/>
</attribute-def>
That way we know that the "connection:min-bits-encryption" only has
meaning when "connection:secure" is marked true.
> > 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 .
I'm glad. So how do we move forward?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
