Spring Book – Chapter 18 – Remoting

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:

  1. In the Spring Configuration file applicationContext.xml, define a bean that needs to be exposed as a remote service using Spring remoting.
  2. In the Spring configuration file, now declare the service exported bean according to the remoting technology used using the bean declared in Step1.
  3. In the Spring configuration file, declare the client proxy bean according to the remoting technology used.
  4. 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-5. Separation of concerns by interfaces and implementations using RMI

Figure 19-6. Abstraction layer of stub and skeleton in the RMI implementation

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:

  1. 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.
  2. Dependency Layer—This layer is responsible for interpreting and managing the various references made from clients to the remote service objects.
  3. 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

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

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

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

Page Visitors: 4802

The following two tabs change content below.
Tomcy John

Tomcy John

Blogger & Author at javacodebook
He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.
Tomcy John

Latest posts by Tomcy John (see all)

Leave a Reply

Your email address will not be published. Required fields are marked *