avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Contents of phoenix-client.jar
Date Sun, 08 Sep 2002 12:20:26 GMT
On Sat, 7 Sep 2002 22:34, Igor Fedorenko wrote:
> Peter Donald wrote:
> > On Sat, 7 Sep 2002 20:03, Paul Hammant wrote:
> [skipped]
> > It will trim down when we move to new component model. I don't think
> > there is any need to change anything until then.
> Where can I find description of this "new component model"? And where
> can I find information about future directions of avalon/phoenix
> development in general?

There is no central place for this sort of information. It is sort of 
scattered through all our mailing lists. We sort of have a list of things to 
do in Bugzilla. You can see this list by clicking on TODO list on Phoenix 

That list of things is not complete. Over the next few days I may try to fill 
it up with some of the other things we need plan to do over time.

The new component model is one of those things that we plan to do. Phoenixs 
model (essentially the BlockInfo files and classes) is great for what Phoenix 
does but it is not extensible enough to handle all component needs. For 
example when we decided we needed to expose management services we had to go 
in and change the BlockInfo file format. I suspect similar things will occur 
when we start supporting factorys, interceptors and so forth.

Rather than constantly extending our model, we can instead choose to use a 
generic and more comprehensive mechanism and thats where the new Component 
model comes in. 

Essentially for every resource that a component needs we have a mechanism for 
allowing the component to declare that it requires that resource. Currently 
Phoenix limits this declaration of resource requirements with respect to 
service dependencies. The new model will allow us to declare requirements on 
context entrys, loggers etc.

To make it more extensible we plan to allow all resource requirement 
declarations to be "extended" by a set of attributes. These attributes are 
key-value pairs that allow you to extend the model in arbitrary ways. Each 
key is in a namespace and can extend things for a particular domain. 

For example, in your case you want to add security when calling services. In 
this case you would define a set of security keys such as

sec:permission (name a permission needed by caller to call method)
sec:role (name a role the caller requires to call method)
sec:run-as (the subject that the method is called as)

Then you would associate them with a service declaration like

<service name="org.apache.MyService">
    <attribute name="doc:display-name" value="My Groovy Service"/>
    <attribute name="sec:role" value="admin"/>
    <attribute name="sec:run-as" value="Fred"/>

Each container could choose to implement these requirements differently. In 
the case of Phoenix we would write an interceptor that knew about the "sec:" 
namespace and could handle it appropriately.

You can find the start of this work in CVS in "jakarta-avalon-excalibur/info". 
However it is still going to change a little. In the current info package 
there is only ComponentInfo objects (equivelent to Phoenix BlockInfo). 
However in the future we plan to add ServiceInfo object (that describes 
metadata about a service, independent of any particular implementation).

A lot of our thinking is inspired by some of the work done by MS with their 
attribute based development. If you are interested in that you can look at 
avalon-dev mail archive for a thread "[AvaloNET] Where two worlds collide... 
not" which points a few links. 

Anyways I will add some more details to the TODO list over next few days and 
hopefully that will give you a bit of an idea about where we are going.


Peter Donald
"Wise men don't need advice. Fools don't take it." 
                        -Benjamin Franklin 

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

View raw message