Exposing POJOs as Remote Services with Spring

Since its introduction with JDK 1.1, RMI has been a dominant protocol for

connecting Java application on both ends of the wire. However, RMI involves a

lot of boilerplate; for example, a remote interface must extend the

java.rmi.Remote interface, generate stubs and skeletons, complicated lookup,

handle RemoteException and MalformedUrlException, etc. So, you can well imagine

the complexity involved in using RMI for this job! Spring simplified the RMI

development experience by providing service exporters out of the box.

Furthermore, Spring provides a



seamless integration with HTTP protocol for exposing POJO components as remote
services, something that was not present earlier and one which has made

developers' life easy. In a series of two articles, we'll explore these two

popular techniques (RMI and HTTP), provided by the Spring framework and that

help expose POJOs as remote services.

Transparent remoting using RMI



In order to transparently expose POJOs as remote services, Spring provides

RmiServiceExporter to export Spring beans over the RMI protocol and

RmiProxyFactoryBean to consume



remote services. In this article, we'll expose a simple service as an RMI
service. To begin with, we'll write a service interface and an implementation

class, as shown below:

package com.pcquest.remoting.service;



public interface rmservice


{


String getResult(String s);


}

As shown in the preceding code snippet, the service doesn't extend the

java.rmi.Remote interface and none of its methods throw java.rmi.Remote

Exception; this removes the boilerplate.

package com.pcquest.remoting.service;



public class rmserviceimpl implements rmservice


{


public rmserviceimpl(){


}


public String getResult(String a)


{


return "Hi "+a;


}


}

The service implementation class is simple. As opposed to traditional RMI

service implementation class, the rmserviceimpl POJO doesn't extend the

UnicastRemoteObject. However, you need to still wire the dependencies in the

Spring configuration file, as shown here:

The plumbing code is simple; as discussed before, the RmiService Exporter is

used to expose any Spring managed bean as an RMI service. The POJO bean is

wrapped inside an adapter class which implements the remote interface as

indicated by the 'service Interface.'

Furthermore, the RmiServiceExporter registers the same under the name

'MyService' and binds with port 1199. Notice that the remote service

implementation is injected into the 'service' property through Dependency

Injection (DI).

Consuming remote services



To consume a remote service, we'll use the Spring's RmiProxyFactoryBean. As

the name suggests, the RmiProxyFactoryBean is a factory bean that creates a

proxy to an RMI service. In our demo example we'll write a POJO which has a

dependency in the remote service (later, we'll wire this depencecy through

Spring DI), as shown here:

package com.pcquest.remoting.client;



import com.pcquest.remoting.


service.*;

public class SimpleObject {



private rmservice remoteService;

public void setRemoteService(rmservice remoteService) {



this.remoteService = remoteService;


}


...

Now, let's look at the Spring configuration file for plumbing all related

dependencies:

As shown, the URL of the RMI service is set through the serviceUrl property.

The serviceInterface property identifies the interface that the remote service

implements. The client will call business methods on the same interface.

Further, after the remote service is resolved, it's injected into the simple
object as discussed before.

Conclusion



Spring provides easy integration points for RMI protocol. However, RMI is Java
based remoting technique; both the client and the server must be written in

Java. Also, RMI uses arbitrary ports for communication; this could cause

problems working across firewalls. In the next part, we'll explore how Spring

supports HTTP remoting.