Tom Hobbs wrote:
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.
I especially like the 'recursive' nature of JERI. The idea of beeing
able to serve a reference to a service that is not even on your VM is
very inspiring.
The wrapper solution presented, did only take into account a 'flat'
service (no value judgement there!). As a thinking excercise i wanted to
take this a step further and think about a 'automatic' recursive
wrapper. To counter transport errors, this would be easy, for service
redundancy this would mean glueing a terracotta cloud behind jini in
order to keep object references.
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? :-)
Yes! :-) Let's "stir the pot" some more!
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
