Remoting Technologies
The development of services that require remote deployment has been eased by the emergence of Spring remoting support in Spring Framework. The mindset that remoting is too complex to implement and, even if achieved, locks your code to a particular programming model is no longer valid.
At present, Spring supports the following remoting technologies:
- Remote Method Invocation (RMI)
- Spring’s HttpInvoker
- Caucho’s Hessian
- Caucho’s Burlap
- JAX-RPC
- JAX-WS and
- JMS
We will now look at these remoting technologies one-by-one in detail so that you can understand the nitty-gritty aspects of each technology.
The basic steps that must be followed to expose a bean as remote service in Spring Framework are consistent, and for various technologies, only the corresponding classes change in each step, as follows:
- In the Spring Configuration file applicationContext.xml, define a bean that needs to be exposed as a remote service using Spring remoting.
- In the Spring configuration file, now declare the service exported bean according to the remoting technology used using the bean declared in Step1.
- In the Spring configuration file, declare the client proxy bean according to the remoting technology used.
- In your client, inject the factory bean declared in Step 3 and use the appropriate method in the exposed remote service.
In the following section we will see applying the above steps to various remoting technologies which Spring Framework supports at present by providing appropriate service exporter and client proxies.
Remote Method Invocation (RMI)
Before we look into Spring’s support of RMI remoting technology, we will understand RMI so that it is clear in all aspects.
Remote Method Invocation (RMI) technology was first introduced in JDK 1.1 to elevate network programming to next level. Although RMI is considered to be easy to use, it is a remarkably powerful technology and exposes the average Java developer to an entirely new paradigm of distributed computing. RMI allows separating the code which defines the behavior ad the code which actually implements the behavior to be separated into different JVM’s making it ideal for modularizing you application. Figure 19-5 shows this concept pictorially.
Figure 19-5. Separation of concerns by interfaces and implementations using RMI
Figure 19-6. Abstraction layer of stub and skeleton in the RMI implementation
As shown in Figure 19-6, the role of various layers in the RMI implementation is as summarized as follows:
- Stub and Skeleton layer—This layer is responsible for intercepting method calls made by the client to the interface and redirecting them to the remote RMI service which is exposed in the server.
- Dependency Layer—This layer is responsible for interpreting and managing the various references made from clients to the remote service objects.
- Transport layer—This layer is complex in nature and is based on TCP/IP connections between machines in the network and provides basic connectivity and some firewall penetration strategies.
RMI uses the proxy design pattern explained in the earlier sections of this chapter. The stub in RMI forms the proxy and the remote service implementation forms the real subject in the proxy design pattern. Skeleton is a helper class whose main responsibility is to carry the conversation with the stub and to do the necessary conversions to talk with the actual implementation object.
Spring supports RMI using org.springframework.remoting.rmi.RmiProxyFactoryBean and org.springframework.remoting.rmi.RmiServiceExporter classes.
RmiProxyFactoryBean is the FactoryBean for RMI proxies, supporting both conventional RMI services and RMI invokers. It exposes the proxied service for use as a bean reference using the specified service interface. Proxies will throw Spring’s unchecked RemoteAccessException on remote invocation failure instead of RMI’s RemoteException.
RmiServiceExporter is the RMI exporter that exposes the specified service as RMI object with the specified name. Such services can be accessed via plain RMI or via RmiProxyFactoryBean.
We will now see the step-by-step configuration required to expose our sample application’s LoyaltyService as a remote service using RMI as the remoting technology. The various steps remain the same as explained in section earlier, only there is change in various classes being used. The steps are as follows:
1. In the Spring Configuration file applicationContext.xml, define a bean which needs to be exposed as a remote service using Spring remoting. Listing 19-1 below shows exposing LoyaltyService bean as remote service in the server side.
Listing 19-1. Bean configuration of LoyaltyService
1 2 3 |
<bean id="loyaltyService"> <property name="customerRepository" ref="customerRepository"/> </bean> |
2. In the Spring configuration file, now declare the service exported bean according to the remoting technology used using the bean declared in Step1. Listing 19-2 shows configuring the service exporter for RMI in the server side.
Listing 19-2. Configuring RMI service exporter as a bean
1 2 3 4 5 6 7 |
<bean> <property name="serviceName" value="loyaltyService"/> <property name="serviceInterface" value="com.mybook.loyalty.services.LoyaltyService"/> <property name="service" ref="loyaltyService"/> <property name="registryPort" value="1099"/> </bean> |
3. In this step, in the Spring configuration file, declare the client proxy bean according to the remoting technology used. Listing 19-3 below shows declaring client proxy in the client layer.
Listing 19-3. Declaring client proxy
1 2 3 4 5 6 |
<bean id="myService"> <property name="serviceInterface" value="com.mybook.loyalty.sevices.LoyaltyService"/> <property name="serviceUrl" value="rmi://host:1099/loyalty/services/loyaltyService"/> </bean> |
4. Now in your client, inject the factory bean declared in Step 3 and use the appropriate method in the exposed remote service. Listing 19-4 shows declaring of the client bean in which client proxy is injected to be used for calling service methods.
Listing 19-4. Injecting client proxy in the client class
1 2 3 |
<bean id="myDesktopUI"> <property name="loyaltyService" ref="loyaltyService"/> </bean> |
Page Visitors: 4713

Tomcy John

Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023