Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

November Discount Launch 2022 – Top
We’re finally running a Black Friday launch. All Courses are 30% off until next Friday:


Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

1. Overview

Java Remote Method Invocation allows invoking an object residing in a different Java Virtual Machine. It is a well-established technology yet a little cumbersome to use, as we can see in the official Oracle trail dedicated to the subject.

In this quick article, we'll explore how Spring Remoting allows to leverage RMI in an easier and cleaner way.

This article also completes the overview of Spring Remoting. You can find details about other supported technologies in the previous installments: HTTP Invokers, JMS, AMQP, Hessian, and Burlap.

2. Maven Dependencies

As we did in our previous articles, we're going to set up a couple of Spring Boot applications: a server that exposes the remote callable object and a client that invokes the exposed service.

Everything we need is in the spring-context jar – so we can bring it in using whatever Spring Boot helper we prefer – because our main goal is just to have the main libraries available.

Let's now go forward with the usual spring-boot-starter-web – remembering to remove the Tomcat dependency to exclude the embedded web service:


3. Server Application

We'll start declaring an interface that defines a service to book a ride on a cab, that will be eventually exposed to clients:

public interface CabBookingService {
    Booking bookRide(String pickUpLocation) throws BookingException;

Then we'll define a bean that implements the interface. This is the bean that will actually execute the business logic on the server:

CabBookingService bookingService() {
    return new CabBookingServiceImpl();

Let's continue declaring the Exporter that makes the service available to clients. In this case, we'll use the RmiServiceExporter:

RmiServiceExporter exporter(CabBookingService implementation) {
    Class<CabBookingService> serviceInterface = CabBookingService.class;
    RmiServiceExporter exporter = new RmiServiceExporter();
    return exporter;

Through setServiceInterface() we provide a reference to the interface that will be made remotely callable.

We should also provide a reference to the object actually executing the method with setService(). We then could provide the port of the RMI registry available on the machine where the server runs if we don't want to use the default port 1099.

We should also set a service name, that allows identifying the exposed service in the RMI registry.

With the given configuration the client will be able to contact the CabBookingService at the following URL: rmi://HOST:1199/CabBookingService.

Let's finally start the server. We don't even need to start the RMI registry by ourselves because Spring will do that automatically for us if such registry is not available.

4. Client Application

Let's write now the client application.

We start declaring the RmiProxyFactoryBean that will create a bean that has the same interface exposes by the service running on the server side and that will transparently route the invocations it will receive to the server:

RmiProxyFactoryBean service() {
    RmiProxyFactoryBean rmiProxyFactory = new RmiProxyFactoryBean();
    return rmiProxyFactory;

Let's then write a simple code that starts up the client application and uses the proxy defined in the previous step:

public static void main(String[] args) throws BookingException {
    CabBookingService service = SpringApplication
      .run(RmiClient.class, args).getBean(CabBookingService.class);
    Booking bookingOutcome = service
      .bookRide("13 Seagate Blvd, Key Largo, FL 33037");

It is now enough to launch the client to verify that it invokes the service exposed by the server.

5. Conclusion

In this tutorial, we saw how we could use Spring Remoting to ease the use of RMI that otherwise will require a series of tedious tasks as, among all, spinning up a registry and define services using interfaces that make heavy use of checked exceptions.

As usual, you’ll find the sources over on GitHub.

November Discount Launch 2022 – Bottom
We’re finally running a Black Friday launch. All Courses are 30% off until next Friday:


Generic footer banner
Comments are closed on this article!