river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: Service Wrapper Example
Date Wed, 24 Feb 2010 09:11:01 GMT
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

View raw message