river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Service Wrapper Example
Date Mon, 15 Feb 2010 10:03:46 GMT
> It is certainly interesting. It would only work when one has only one
remote reference in memory, would it?
> I mean, if you lookup the main service object and via a remote call it
returns some other remote reference,
> and you lose contact, how would it recover? Or is the intention only to
iterate over multiple instances of one
> service during setup?

Well, assuming I understand your question correctly.  In any one JVM you
could have as many "ServiceWrapper" instances as you want, (all created with
the same ServiceTemplate), which may or may not all be pointing to the same
remote service.  The way I have used it before is with static method calls,

e.g.

MyService myService1 = ServiceWrapper.findMeAService(someTemplate);
MyService myService2 = ServiceWrapper.findMeAService(someTemplate);

Here, there is no guarantee as to whether myService1 and 2 are wrappers to
the same remote proxy or not.  But you can guarantee that two remote lookups
have been made and two proxies have been returned.

Certainly in my experience, detecting errors and recovering is always the
job of the client.  To use a daft example; why would a web page detect that
a browser has unexpectedly disappeared and try to find a new browser to
display itself on?  But in the event of a web server going down, it's always
the browser/etc that needs to go any find another copy of the page
somewhere.

The ServiceWrapper example I provided essentially wraps all calls to the
remote proxy, so if any kind of exception is thrown on invocation, that
exception can be caught and handled in the wrapper.  In the case where the
service has gone away or just broken, the wrapper can attempt to find a
replacement service and then reissue the method call.  This would manifest
itself in the client as just a remote call that takes slightly longer to
execute (because another lookup is being done).

If you have a situation where your remote proxy needs some kind of state,
then you have a more complex job of getting any new service to the same
state as the old one before the ServiceWrapper executes the original method
call.

What the wrapper does is essentially provide a Reflection-based AOP around
all calls to the service, so you can make it as complex or simple, generic
or business-specific, as your needs require.

This style of service wrapping worked very well in a complex trading
platform that I was previously involved in.  It enabled us, with the
provision of some additional business rules - especially regarding state, to
take down services at random and have the system automatically recover
without interrupting the client.  It truly was a self-healing system.



On Fri, Feb 12, 2010 at 9:22 PM, Sim IJskes - QCG <sim@qcg.nl> wrote:

> Tom Hobbs wrote:
>
>> Hi,
>>
>> I mentioned in another thread that I had come across code which provides
>> service fail over and auto-rediscovery.  I've posted details of the kind
>> of
>> code that was used to (note this has been reinvented in my head just now
>> and
>> only loosely tested);
>>
>> http://wiki.apache.org/river/AutomaticServiceReplacement
>>
>> I hope that someone finds it useful and/or interesting.
>>
>
> It is certainly interesting. It would only work when one has only one
> remote reference in memory, would it? I mean, if you lookup the main service
> object and via a remote call it returns some other remote reference, and you
> lose contact, how would it recover? Or is the intention only to iterate over
> multiple instances of one service during setup?
>
> It is certainly something what starts to be a recurring theme (for me), a
> soon as you start to offer a more complex service, how do you handle errors?
> It looks to me, that the client is totally responsible for recovery, and
> that all of jini is built with this premise. All the recovery you get at the
> moment is the TCP retry mechanism. But if a laptop resumes from a suspend
> and gets a new IP address via DHCP an error is thrown back to the client
> (user).
>
> Currently i have some recovery built into our 'rpc/ip through http tunnel',
> but this covers only transport errors. No recovery to fix disappearing
> individual service instances in a redundant cluster.
>
> I wonder if it was the intention by 'the elders' that we go back to the
> lookup service, and try to find a service again. I'm not sure if we can hide
> this recovery in a serviceproxy. Any ideas?
>
> Gr. Sim
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message