avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: distributed containers
Date Wed, 05 Nov 2003 02:20:13 GMT
On Wednesday 05 November 2003 08:47, Stephen McConnell wrote:
> hammett wrote:
> >----- Original Message -----
> From: "Stephen McConnell" <mcconnell@apache.org>

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

The point is, there are no assurances!!! There can't be no assurances. Trying 
to pretend that there is, will work in most case, but will fail miserably 
when things starts to be less reliable. And we want to create a ROBUST 
environment, not an "Assured" environment, that is plain stupidity.

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

Yes, you are right that as much tricky code as possible should be moved to the 
container, BUT we need to establish a contract between the Container and the 
client component, so that the container can say; 

"Hey, I know you want service A, but sorry, there is none available at the 
moment. Hang in there, I'll get back to you when I have found one."

After which the client component could;
1. Block (for a while) when others are requesting service that depends on the 
availability of other services.
2. Throw a defined NotCurrentlyAvailableException.
3. Pretend (bad! but have help me in the past)
4. Queue and service later.
5. Mimick.

Whatever it does, it is safe to say that the container have no clue what is 
the best "Fall-back strategy".


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

View raw message