avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin Container
Date Wed, 28 Aug 2002 22:57:21 GMT


Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>Berin Loritsch wrote:
>>
>>
>>>Outward flows of information include:
>>>
>>>* getName() (not setName())
>>>
>>
>>This was a convinience operation only used in logging messages by a 
>>parent container.  Its easily removed.

Removed.

>>
>>>* Container createContainer(...)
>>>
>>
>>Can be removed from the interface.
> 
> 
> :) That would make me happy.

Be happy - it's done!

> 
>>>* getState()
>>>
>>
>>This one is more complicated.  Invoking suspend on a 
>>container results in the invocation of supend on all 
 >>subsidiary containers and the parent basically waits for
 >>all subcontainers to achieve suspension before
>>considering itself suspended.  This was not in the interface 
>>before but the introduction of the ability to plug-in a 
 >>foreign container in a heirachy complicated things. I've got
 >>some ideas but I need to think some more first.
> 
> 
> Right.  This stems from the decision to have each and every container
> run in its own thread.  The simple solution would be to have the
> suspend() and resume() methods to block until they are completed.
> It is perfectly reasonable to do that, and manage the number of threads
> you want to use for the purpose of simultaneously suspending and
> resuming the containers within the parent container.

As part of looking at refactoring this I've been digging into the 
excalibur/event package.  One problem I'm comming up against is a lack 
of examples or cookbook style documentation - are their sources of 
examples of the usage of the event.command utilities hidden away anywhere?

> 
>>>* getResources()
>>>
>>
>>This is part of the service functionalityb of a container.  
>>Keep in mind that a container acts as a factory of services 
 >>derived from the component implemetation it is managing.  The
 >>getResources() method isolates managed compoents from the
 >>services they provide.  There is an  alternative - namely the
 >>publishing of the established service back to the component
 >>manager (classloader) which may be more consitent however
>>- I think this operation will still be needed in management 
>>applications (but that could be split out to a different 
 >>interface).
> 
> 
> In my mind service == component, so could you help me understand
> your distinction between the two?

component == implementation
service(s) == work interface(s) declared by component

> Also understand that not all containers will want to expose
> any "resources" (is that supposed to be the same as management
> interfaces?) so it should be moved into a separate interface.

The management interface is another topic - seperate interfaces will be 
needed for that.  I referring only to the work interface when I use the 
term service.  Normally this will be proxied - but proxies are not in 
place today (a matter of prioritising the list).

> 
> 
> 
>>>>And the reason is:
>>>>
>>>>1. container are not peers when we are looking at them in terms of
>>>>component management frameworks - they a hierarchical and are 
>>>>subject to constraints concerning access to classloaders, kernel 
>>>>resources and so on.  However, when we get to the management of 
>>>>the services that provide 
>>>>   
>>>>
>>>
>>>Not all containers are peers though.  I need to throw together some 
>>>real art (PNG or GIF for your preferred format?) to 
>>>demonstrate what I mean.
>>>
>>
>>GIF
> 
> 
> I will throw something together soon then.


I'm working through the other emails now.


> 
>>There is some enhancements that need to be applied to the 
>>thread model - basically moving thread establishment from 
>>the container to its parent. 
> 
> 
> Right.
> 
> 
>> That's going to have some impact on the control mechanisms 
>>and should enable some simplification of the interfaces (and 
>>implementation inside DefaultContainer).
> 
> 
> correct.
> 
> 
>>>However, there are many ways to publish a component, and to 
>>>mark a component as publishable.
>>>Keep in mind that the container does not have to respect the 
>>>publishable attribute.  It is perfectly valid to be more 
>>>restrictive, but it is definitely not valid to be more lenient.
>>> 
>>>
>>
>>Absolutely - the intention concerning the getResource() operation 
>>is that a container is always in control of the resources it
>>exposes.  I'm also working on a URL based container access 
>>mechanism - its working with remote containers at the moment and I 
>>have in mind a generalization of this that could replace the 
>>getResources() operation.  It would basically provide similar 
>>functionality to the ECM lookup semantics - but service instances 
>>would be packaged under a java.net.URL. Different URL handler then 
>>take care of the interaction with a local or remote containers 
>>during service resolution.
> 
> 
> It sounds interesting to say the least.  I still don't have the "big
> picture" of exposing the resources that you describing.  Some of the
> clouds have moved out of the way, but it seems we have some heavy
> cloud cover on this one.

I would be kidding if I said that everything was clear-skies over here 
(but I wouldn't call it overcast either).

;-)

I'll try to fill in some of the gaps as answers to the other emails you 
have sent through this evening.  There is perhaps one area where I'm 
looking at things differently.  We share the same ideas concerning 
component management and the restrictions that apply when building the 
component system.  However, when that system is built, services and 
established, etc.  I think we have take a step back, place the component 
hierachy on its side and look at it from the edge.  What we see is a set 
of services.  If we tilt the page back just a little, you will notice 
that these services are popping up from identifiable containers (i.e. 
the container hierachy provides an addressable set of established 
services).  This is where the URL principals come in - a URL declares 
the path to the service and can be used to activate the service. All 
this is doing is saying there are two distinct viewpoints to a container 
- one is the type/component management infrastructure viewpoint, the 
other is the service network viewpoint.  While a container is component, 
I consider it a special type of component in that it is exposing a 
dynamic service content (qualified and controlled by policies etc.).

But keep in mind that the export side is relatively uncharted territory 
at this time - still experimenting.

Cheers, Steve.


-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net


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


Mime
View raw message