avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [RT] SOC & Meta Information
Date Wed, 04 Sep 2002 21:59:25 GMT
On Wed, 4 Sep 2002 23:50, Berin Loritsch wrote:
> > 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.

Have a look at the attribute list I sent. They have an "applicability" column. 
Some attributes are applicable to either the component or the service while 
some are restricted to service (interface) and some are restricted to 
component (implementation).

Consider that it is reasonable to assume that;
* an interface that extends Remote indicates that all implementations are 
"remotable" (whether they are capable of being exported is independent - 
especially if you use something like altrmi).
* an interface FooMBean is a management interface and all implementors will 
likely treat it as such

> Same with "instrumentation"--not all implmentations of a service (aka
> work interface) will be instrumented.

instrumentation is definetly an implmentation thing

> Things like "mx:*" (management specific) would be welcome in the
> Service interface, However all the other aspects you listed would
> be component implementation sepecific.

I am not so sure. I think it is the choice of the component/service writer for 
certain things whil eother things are clearly only applicable to one level or 

> 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.

Again - I disagree. It needs to be done on per-attribute basis. ie Usually MX 
or Remote will be inheritable but selection criteria will not be.

> > 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.

Because that is not true. All my parameters could be referring to RMI 
interfaces (thus pass-by-value == false) but it would be perfectly valid 
remote object (as all parameters would be pass by reference).

> 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.

Agreed. And if the component absolutely requires that certain attributes are 
required then it does something like "feature:required=remote" and the 
container should not load component if it does not support all of those 

> 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.

Some of them can be supported while some will needed to be supported by 
alternative mechanisms.

> > > 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?

I would say that the best thing to do is for you to convert fortress to using 
a meta-info based system. You will probably encounter things that have yet to 
be encountered and we can deal with them then. My main headache at the moment 
is trying to figure out an easy way of using attributes from a container 
writers point of view. Essentially how do you enforce those definitions you 
gave and how do you access values - especially when some are inherited and 
some are not etc.

After I figure that one out we can merge the best stuff together and go with 

Peter Donald
 Logic: The art of being wrong with confidence...

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message