avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: distributed containers
Date Wed, 05 Nov 2003 00:47:50 GMT


hammett wrote:

>----- Original Message ----- 
>From: "Stephen McConnell" <mcconnell@apache.org>
>
>  
>
>>Not really. :-)
>>    
>>
>
>Hmmm ...
>

:-)

>
>  
>
>>In a distributed solution the container that is establishing a service
>>is responsible
>>for santiy checking.
>>    
>>
>
>Exactly, but on demand, when a component/service is requested. I think in a
>distributed environment the container should start up with few - or none -
>information about the services it should expose or consume. These will be
>discovered in the right time, when one feels like requesting/exposing them.
>It is totally different from what we have now, as Niclas already stated.
>

What we have now is "assurance of service availablility" before deployment.
This is not service aquisition - its simply validation that a deployment
scenario is viable.  In a distributed scenario this means that the container
is still responsible for delegating that assurance responsibility towards
one or more candidate providers (and by provider I mean some remote system
that can provide a stateemment of assurance).

>>But there is a piece missing - a protocol dealing
>>with inter-container communi[c]actions concerning service availablity.  
>>For example, the client container would aquire a service from a remote 
>>container and probably register a listerner on the remote container.
>>    
>>
>
>Easy man! :-)
>That is a possible strategy, but is not the one.
>
>  
>
>>If the remote is taking down the component that
>>is providing the service, it can notify client containers.
>>    
>>
>
>On my head the Client/Server should not create any kind of link. The client
>just can't rely on any notification of the server is taking down. In fact
>the client doesnt know any server; if it needs a service, it shout and
>obtain someone to help it. After a while, if it needs the same service
>again, it should shout again.
>

My turn .... ummmm!

There are a bunch of models that can be applied concerning service 
aquisition
but at the end of that day, you have a link between a client and a 
server and
you choose to manage that link or to leave it up to the component.  
Leaving it
up to the component just results in more code in the component dealing with
remoteness considerations.  We want to eliminate that - which means 
shifting
monitoring and availablity management down into the container.  That means
that a container is dealing with distribution specifics - e.g. in an IIOP
sceanrio this means handling transient exception, establishing and 
maintaining
event channels, populating value type, establishing pricipals, etc.  
I.e. the
container is the client and has reasonably imnport role to play in properly
isolating the component from the distribution strategy.

>>In this model the client component is totally unaware that the service
>>it is provided with is remote.
>>
>
>If we can do that, it would be very very nice.... :-)
>  
>

Technically it is dooable.  But there are a few prereqs we need to put in
place inside Merlin concerning custom appliance establishment.  Once that
is done, we will have the framework for experimentation.

CHeers, Steve.


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

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




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


Mime
View raw message