Hi Sim, You did indeed answer my questions. Thanks for the "registered vs exported" description. I've spent so much time looking at Jini/River services that I tend to forget that other things exist!
The only thing I think needs clarification is this bit; > Assuming we agree, if you have a wrapped service (with error recovery) but the wrapper is allowed to return a > Remote reference which is passed through the program (without beeing wrapped) a transport (or remote) > error will cause effects outside the control of the wrapper. (So you basically need a recursive wrapper to > counter this.) You're right, in that if you manage to get hold of a proxy that hasn't been wrapped, then any kind of exception in any layer could occur anywhere that the client code uses that proxy. But isn't this obvious? If you have a strategy for self-healing then you need to make sure your client code accessing the proxies only through that strategy. In this case, wrapping the remote reference in a Proxy. That wrapped proxy is then passed around inside the client code. Certainly in "normal" circumstances, this Proxy wrapper wouldn't allow access to the underlying wrapped remote proxy so all calls would go through the reflection code without the client code being any wiser. The "service finding" mechanism inside your strategy can be River or normal RMI or whatever. Does that make sense? Are we argumentatively agreeing with each other? :-) Cheers, Tom
