RE: [Springframework-developer] HTTP-based remoting with Java serialization

[Oliver H. <Ol...@ou...>]

J=FCrgen, all,

I committed my remoting code to the Spring RCP sandbox last Friday but =
was holding off on letting anyone know as I haven't ironed out the proxy =
generation just yet (not sure whether to use the Spring or JDK proxy =
code), check it out.=20

> What approach is your current prototype using? Do you use
> org.springframework.remoting.support.RemoteInvocation or some=20
> custom class for representing invocations? What do you think=20
> about the above approach, and about adding generic support=20
> for retry strategies across all of Spring's supported=20
> remoting protocols?

Internally I use my own custom invocation (called .Request) and =
InvocationResult (.Reply) classes but essentially the invocation class =
is almost identical to the Spring RemoteInvocation (in my class the =
parameter types are encoded in the method name rather than being =
transferred as an array). I also have a set of drop in replacements for =
HessianProxyFactoryBean and HessianServiceExporter with full support =
BASIC authentication but on top of that my system also has pluggable =
protocols and transports (though I've only implemented HTTP and =
serialization).

The most interesting thing IMO from my code is probably the retry stuff. =
The biggest issue with any kind of retry system is to make sure we =
*never* invoke a remote method twice unless we know for sure it is safe =
to do so. I.e. We certainly wouldn't want any CRUD operation to be =
executed twice but perhaps we wouldn't mind if a query operation was. To =
allow the remoting system to make a decision about retry I have the =
following:

public interface RetryDecisionManager {
    public boolean shouldRetry(Request request, int retryNumber, =
SimpleRemotingException e);   =20
}

And to help the RetryDecisionManager every SimpleRemotingException has a =
property "recoverable". Throughout my code wherever a =
SimpleRemotingException is thrown I've tried to categorize the =
recoverability of the exception into 3 states:

1) Recoverable=3DYES is any exception where the system is sure that the =
remote method was *not* invoked.
2) Recoverable=3DNO is any exception where the system is sure that the =
remote method *was* invoked. =20
3) Recoverable=3DMAYBE is any exception where the system has no idea =
whether the remote method was or was not invoked. This is the most =
common case.

So a simplistic RetryDecisionManager might just be something like this:

 // Only retry when we are certain the remote method was not invoked and =
only
 // retry a maximum of 10 times.
 public boolean shouldRetry(Request request, int retryNumber, =
SimpleRemotingException e) {
	return e.isRecoverable() =3D=3D Recoverable.YES && retryNumber < 3;
 }=09

A more complex one might also have a look at the request:

 // Only retry when we are certain the remote method was not invoked or =
the
 // remote method is a finder.
 public boolean shouldRetry(Request request, int retryNumber, =
SimpleRemotingException e) {
	return e.isRecoverable() =3D=3D Recoverable.YES=20
		|| request.getMethodDesc().indexof("find") !=3D -1;
 }=09

Or perhaps even ask for some user input:

 public boolean shouldRetry(Request request, int retryNumber, =
SimpleRemotingException e) {
	return JOptionPane.showConfirmDialog(parentComponent, "There was a =
problem connecting to the server: " + e.getMessage() + ". Do you wish to =
retry?") =3D=3D JOptionPane.YES_OPTION;
 }


Another nice feature is that authentication is done using a callback =
which is invoked for every request:

  public interface AuthenticationCallback {

    public Authentication authenticate(Request request);
  }

  public interface Authentication {

    public Object getPrincipal();

    public Object getCredentials();
  }

At the moment the system only does BASIC authentication but other =
methods could be added.


In addition to this there's also some progress tracking support code and =
invocation interception stuff bit this is not very well developed.=20

Anyway please check it out and let me know whether you think any of it's =
useful. I think it would be a big value add if Spring provided a really =
nice remoting implementation with good retry, progress and security =
support.=20


Ollie