First contact with Spring RMI

For years, I’ve been surrounded by components using Java RMI, but never ever needed to implement anything using it. So when chance came, I went the Spring way, as I knew it had support for transparently exposing beans through RMI. And it already was a declared dependency for the project.

I read the docs. It looked easy: create a pojo, declare a bean and publish the bean.

But it is not that easy. Doing that will only expose a Spring-specific wrapper, which non-Spring clients can’t use (incidentally, the RMI clients weren’t using Spring).

What annoyed me a bit is how deep is this information is buried in the manual. It is at the end of the chapter in a section called “Considerations when choosing a technology“, in a paragraph discussing Spring HTTP invoker:

Note that HTTP invokers are not only limited to Java-to-Java remoting but also to Spring on both the client and server side. (The latter also applies to Spring’s RMI invoker for non-RMI interfaces.)

There’s no reference to this limitation in the section devoted to RMI. Of course, once you know the story, you can see this paragraph on the introduction as a warning:

Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the RmiServiceExporter Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).

After googling around and looking in the forums, I learned that using RMI with Spring boils down to one of two options:

  1. You can transparently expose any interface through RMI, as long as both ends use Spring to encapsulate the RMI communication.
  2. You can create a class extending java.rmi.Remote, where every method throws java.rmi.RemoteException. Doing this, your RMI service can be consumed by any RMI client, but you:
    • Explicitly depend on RMI.
    • Need to use rmic to create the stubs and distribute them with the server.

If you’re interested, because of the requirements for the clients I had to go with option 2.

Spring documentation is excellent (specially compared with other popular open source projects) and this issue is a minor one, so don’t read this post as a bash against Spring.

About these ads


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: