> 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.
Thats what I tried to say. But my bad english strikes again :-) > 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). Yes, but not at start up. Thats is my point. > My turn .... ummmm! Grrrr! :-) > 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. But I didn't say we should leave to the component the burden of remotenes. :-) I tried to say the client container shall not have a permanent link to one or more servers. In this distributed environment stations could crash, get rebooted, crash again - Windows!! - and the client should not rely on server standing. > We want to eliminate that - which means > shifting > monitoring and availablity management down into the container. Yes, I agree we want to eliminate it, but we should try different heuristics for that. One shall pick one that represents his environment. > 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. 'Dooable' is a real word? I must confess I spent some seconds trying to figure it out :-P I'll play around with this idea this weekend - if I don't have to work - but without merlin in the first moment (I'm not as familiar with merlin as I want to be) then, after some brainstorms and RT we can plug it all together, what do you think? ( No ummmmm, please! :-PP ) Regards, hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
