You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/09/03 16:26:24 UTC
[RT] SOC & Meta Information
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).
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:
<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>
This would allow us to verify that we can differentiate between for
component
definitions. Other attributes may be legal, but they are purely
informational,
and not proper criteria to search for the best implementation. Using an
Attribute Definition, we can declare a set of attributes that are legal
for
the container to consider. The rules for the attribute defs are as
follows:
TYPE ACTION
------- ------
boolean Absolute criteria--either true or false. A component must
declare its value, and if we need a component with a true
value then the container must supply it.
integer An integer number. It is a relative criteria that allows
the
container to choose the best implementation based on the
"weighting" criteria. The "weighting" attribute allows us
to
specify a preference for "higher" numbers, "lower"
numbers, or
"absolute" matches. The default value is always zero.
number Any number, can be floating point or integer. It follows
the
same rules as the ones for "integer".
enumeration A set of known string values. The list can be "inclusive"
or
"exclusive". An "inclusive" list of values will allow
other
values than what are listed. An "exclusive" list will
throw
a validation error if a component provides a value not in
the
list. There must be one value that is declared the
"default".
Resolution follows matching criteria.
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.
What do you all think?
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 5 Sep 2002 00:06, Nicola Ken Barozzi wrote:
>
>>- avalon:activation I don't understand the implications completely, and
>>we would need to define what a "partition" is, as said in previous mails.
>
>
> partition is essentially a container agnostic way of describing a single
> namespace of components. All components in a partition are in same namespace
> as one another (ie can not have two with same name usually).
>
> Consider cocoons sitemaps, myrmidons scopes, phoenixes application, merlins
> container. All are partitions of components.
I still see them as containers in a multi-level container hierarchy...
> Activation essentially indicates when a component is started. Is it started
> when partition is started (like in phoenix), or is it just-in-time (like in
> cocoon for ThreadSafe components) or will it be activated when required and
> shutdown when no longer required (as per most poolable objects)
Ah, ok, I understand this. :-)
>>- feature:required I think I prefer this to feature:featurename,
>>because it specifies if it's required, without semantics on how to
>>declare it
>
>
> yep.
>
>
>>- What's the difference between doc:description-key and doc:i18n-bundle?
>
>
> i18n is the name of bundle the strings are stored in. Usually this will be
> side-by-side component ala
>
> com/biz/Foo.class
> com/biz/FooInfoResources.properties
>
> However you may need to use a different resource bundle for whatever reason.
> The key is just the key you use to lookup the bundle.
Ok, I just don't have the need for it now, since a good naming scheme is
sufficient IMHO.
>>I think I like this :-)
>>One thing is that I would like to see maybe
>>
>> avalon:activation -> avalon:lifestyle.activation
>> feature:required -> avalon:feature.required
>> doc:description -> avalon:doc.description
>
>
> Starts to get a little verbose...
Then how do you solve the javadoc name clashes?
>>What about the method descriptions you were previously talking about?
>
> Bug me on the weekend and I will send what I have ;)
|||||
(^-^)
O
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Peter Donald <pe...@apache.org>.
On Thu, 5 Sep 2002 00:06, Nicola Ken Barozzi wrote:
> - avalon:activation I don't understand the implications completely, and
> we would need to define what a "partition" is, as said in previous mails.
partition is essentially a container agnostic way of describing a single
namespace of components. All components in a partition are in same namespace
as one another (ie can not have two with same name usually).
Consider cocoons sitemaps, myrmidons scopes, phoenixes application, merlins
container. All are partitions of components.
Activation essentially indicates when a component is started. Is it started
when partition is started (like in phoenix), or is it just-in-time (like in
cocoon for ThreadSafe components) or will it be activated when required and
shutdown when no longer required (as per most poolable objects)
> - feature:required I think I prefer this to feature:featurename,
> because it specifies if it's required, without semantics on how to
> declare it
yep.
> - What's the difference between doc:description-key and doc:i18n-bundle?
i18n is the name of bundle the strings are stored in. Usually this will be
side-by-side component ala
com/biz/Foo.class
com/biz/FooInfoResources.properties
However you may need to use a different resource bundle for whatever reason.
The key is just the key you use to lookup the bundle.
> I think I like this :-)
> One thing is that I would like to see maybe
>
> avalon:activation -> avalon:lifestyle.activation
> feature:required -> avalon:feature.required
> doc:description -> avalon:doc.description
Starts to get a little verbose...
> What about the method descriptions you were previously talking about?
Bug me on the weekend and I will send what I have ;)
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] SOC & Meta Information
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > Anyway, very nice! :-D
> > I also think that some of these can be checked compiletime, like
> > stateless I think.
> >
> > Some considerations:
> >
> > - avalon:activation I don't understand the implications
> > completely, and
> > we would need to define what a "partition" is, as said in
> > previous mails.
> >
> > - feature:required I think I prefer this to feature:featurename,
> > because it specifies if it's required, without semantics on how to
> > declare it
> >
> > - What's the difference between doc:description-key and
> > doc:i18n-bundle?
> > Can't we simply supply i18n bundles for the descriptions?
> If instead
> > it's for the component to supply its i18nzed strings, it's
> > not a doc: ...
> >
> > I think I like this :-)
> > One thing is that I would like to see maybe
> >
> > avalon:activation -> avalon:lifestyle.activation
> > feature:required -> avalon:feature.required
> > doc:description -> avalon:doc.description
> >
> > or something like it, to prevent nasty clashing with eventual
> > additional
> > javadoc tags being used (especially feature and docs that are
> > common words).
>
>
> Another set of attributes that would make sense would be if certain
> components *could* be integrated into a SEDA style architecture. In
> Avalon land, we are calling it SILK for the time being. We can wrap
> traditional components with a SEDA stage, which would interpret the
> events and send them to the component in question. Since the stage
> becomes a special client, the attributes are toolkit specific: i.e.
> if a container supports SEDA, then use this Stage class.... The
> important thing here is that any SEDA compliant implementation must
> be threadsafe/reentrant/sharable (at least currently).
I forgot to post the attribute that would be *Service* specific:
silk:stage-class = ........
Of course things could be reversed and the Stage would be treated as
a first class type, which would depend on the referenced component....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] SOC & Meta Information
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Anyway, very nice! :-D
> I also think that some of these can be checked compiletime, like
> stateless I think.
>
> Some considerations:
>
> - avalon:activation I don't understand the implications
> completely, and
> we would need to define what a "partition" is, as said in
> previous mails.
>
> - feature:required I think I prefer this to feature:featurename,
> because it specifies if it's required, without semantics on how to
> declare it
>
> - What's the difference between doc:description-key and
> doc:i18n-bundle?
> Can't we simply supply i18n bundles for the descriptions? If instead
> it's for the component to supply its i18nzed strings, it's
> not a doc: ...
>
> I think I like this :-)
> One thing is that I would like to see maybe
>
> avalon:activation -> avalon:lifestyle.activation
> feature:required -> avalon:feature.required
> doc:description -> avalon:doc.description
>
> or something like it, to prevent nasty clashing with eventual
> additional
> javadoc tags being used (especially feature and docs that are
> common words).
Another set of attributes that would make sense would be if certain
components *could* be integrated into a SEDA style architecture. In
Avalon land, we are calling it SILK for the time being. We can wrap
traditional components with a SEDA stage, which would interpret the
events and send them to the component in question. Since the stage
becomes a special client, the attributes are toolkit specific: i.e.
if a container supports SEDA, then use this Stage class.... The
important thing here is that any SEDA compliant implementation must
be threadsafe/reentrant/sharable (at least currently).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Wed, 4 Sep 2002 21:22, Peter Donald wrote:
>
>
>>>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.
>
>
> And this time I made it into a jar so the list manager will not strip it.
Ah, I was still searching on the *mailing* list, thanks you found out
the ... strip ;-)
Anyway, very nice! :-D
I also think that some of these can be checked compiletime, like
stateless I think.
Some considerations:
- avalon:activation I don't understand the implications completely, and
we would need to define what a "partition" is, as said in previous mails.
- feature:required I think I prefer this to feature:featurename,
because it specifies if it's required, without semantics on how to
declare it
- What's the difference between doc:description-key and doc:i18n-bundle?
Can't we simply supply i18n bundles for the descriptions? If instead
it's for the component to supply its i18nzed strings, it's not a doc: ...
I think I like this :-)
One thing is that I would like to see maybe
avalon:activation -> avalon:lifestyle.activation
feature:required -> avalon:feature.required
doc:description -> avalon:doc.description
or something like it, to prevent nasty clashing with eventual additional
javadoc tags being used (especially feature and docs that are common words).
What about the method descriptions you were previously talking about?
Anyway, cool :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] SOC & Meta Information
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> > So reentrant implies threadsafe. (But not the other way around.)
>
> Only in sensible systems ;) EJBs are not thread safe but can
> be reentrant ;)
To end this nitpicking of a nitpicking (nitpickings are not safe in
mailing list threads, and may not be re-entered), just a quick note
to those who read this and wonder just what the **** we're on about:
http://www.jguru.com/faq/view.jsp?EID=788123
Actually, you have confused concurrency control and "re-entrant" -
re-entrant is something different
Nick Minutello, Mar 10, 2002
The Re-entrant field has nothing to do with concurrency and
threading
[...which is the way Peter used it...]
(though, thread-safety is usually what re-entrant implies).
[...which is what I said...]
The re-entrant flag is there to allow loop-back calls on an entity
bean.
it is best illustrated by an example: If there are 2 entity beans A,
B, and there is a call made on beanA which calls a method on beanB
which in turn makes a call on beanA, you effectively have a
loopback.
Now, if re-entrant is not set, the container will throw an exception
at this point. If re-entrant is set, the container will permit the
loopback call.
(...)
> I was only putting it in so that Paul if he wanted to use it
> in EOB. However I
> don't think it will be useful in containers that are not
> focused on biz
> objects. (ie all the other containers).
OK, in that case - keep it.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Peter Donald <pe...@apache.org>.
On Wed, 4 Sep 2002 23:59, Leo Sutic wrote:
> Nitpicks:
>
> avalon:reentrant
> Component, Service
> true
>
> Indicates that the artefact is capable of having the
> same thread enter component multiple times in same
> call stack. ie A thread enters Component A, then enters
> Component B and if it is capable of re-entering
> Component A then Component A is said to be reentrant.
>
> That describes the behaviour of re-entrant *locks* but not of re-entrant
>
> routines. A lock is re-entrant if you can do multiple acquire()s on it,
> as long as those acquire() come from the same thread. In general, code
> is
> re-entrant if it does not access any data outside of itself.
>
> For example, a method that only accesses local variables or the
> parameters
> passed to it.
okay.
> So reentrant implies threadsafe. (But not the other way around.)
Only in sensible systems ;) EJBs are not thread safe but can be reentrant ;)
> + consider whether it is needed at all. I see some fairly difficult
> problems
> that the container must solve if it is to magically make every
> component
> reentrant on demand. (For example, Component A is not re-entrant, but
> calls
> component B. B now calls A. What should the container do? Plus, the
> only time
> you'll get something like this is when you have circular dependency -
> seems
> like a waste of time to me to code for that case...)
I was only putting it in so that Paul if he wanted to use it in EOB. However I
don't think it will be useful in containers that are not focused on biz
objects. (ie all the other containers).
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] SOC & Meta Information
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Nitpicks:
avalon:reentrant
Component, Service
true
Indicates that the artefact is capable of having the
same thread enter component multiple times in same
call stack. ie A thread enters Component A, then enters
Component B and if it is capable of re-entering
Component A then Component A is said to be reentrant.
That describes the behaviour of re-entrant *locks* but not of re-entrant
routines. A lock is re-entrant if you can do multiple acquire()s on it,
as long as those acquire() come from the same thread. In general, code
is
re-entrant if it does not access any data outside of itself.
For example, a method that only accesses local variables or the
parameters
passed to it.
So reentrant implies threadsafe. (But not the other way around.)
You may have a need to declare an attribute that has the meaning you
specified,
but I would:
+ think twice before naming it "reentrant"
+ consider whether it is needed at all. I see some fairly difficult
problems
that the container must solve if it is to magically make every
component
reentrant on demand. (For example, Component A is not re-entrant, but
calls
component B. B now calls A. What should the container do? Plus, the
only time
you'll get something like this is when you have circular dependency -
seems
like a waste of time to me to code for that case...)
/LS
> From: Peter Donald [mailto:peter@apache.org]
>
> On Wed, 4 Sep 2002 21:22, Peter Donald wrote:
>
> > > 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.
>
> And this time I made it into a jar so the list manager will
> not strip it.
>
> --
> Cheers,
>
> Peter Donald
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Peter Donald <pe...@apache.org>.
On Wed, 4 Sep 2002 21:22, Peter Donald wrote:
> > 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.
And this time I made it into a jar so the list manager will not strip it.
--
Cheers,
Peter Donald
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
Re: [RT] SOC & Meta Information
Posted by Peter Donald <pe...@apache.org>.
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
another.
> 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
features.
> 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
that.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [RT] SOC & Meta Information
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [RT] SOC & Meta Information
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>