On Wednesday 05 November 2003 08:02, Stephen McConnell wrote: > In this model the client component is totally unaware that the service > it is provided with is remote.
And I somehow doubt that is feasible. Software is either written to handle "service availability" < 100% or it is not. RMI was under heavy fire initially because RemoteException was not a RuntimeException and people want the "remoteness" to be hidden/transparent, BUT the argument was (and is), if the application is not explicitly designed to handle network failures, it won't do well in real world situations. And the more I think about it, the stronger I feel we are at the same position here. To proceed with distributed containers, I'm now convinced that an Availabilty contract must be established between container and client component. And since I have shown that it is almost a necessity for the Service specification to declare its intention of being Remote by throwing RemoteException on all methods in the interface, there will be at least in implicit way to determine a remote capable service implementation. Exactly how an Availability contract is to be defined is down to semantics, and we can start that later, once we agree that "transparent distribution" is probably not feasible. The "up-side" is that it will also allow containers to easily upgrade services, just announce to clients that the service is not availble, chuck out the classloader and classes, and reload, et cetera... And moving agents, and self-configuring systems, and...., and... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
