----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]>
> 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. > But there is a piece missing - a protocol dealing > with inter- > container communityactions 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. > 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.... :-) hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
