Spring Remoting (Часть 1): RMI

Иногда появляется необходимость наделить модульностью Spring-приложения по аналогии с JavaEE-приложениями. Типичный пример - нужно разработать приложение, которое будет использоваться другими приложениями для доступа к БД. Следовательно, между приложениями каким-то образом должно быть реализовано взаимодействие. Ответ на вопрос "А зачем?" достаточно прост: при таком подходе приложения-клиенты ничего не знают о конечной реализации, которую можно будет изменять, не внося изменения в клиенты (например, вместо Hibernate использовать MyBatis или вместо MySQL - MongoDB).

Spring Framework предоставляет большое количество возможных реализаций взаимодействия между приложениями: RMI, Hessian/Burlap, веб-сервисы, JMS, JMX, JCA и даже собственный сервис вызова компонентов через HTTP и интеграцию с EJB. Самым простым, с точки зрения разработчика, будет вариант с использованием RMI.

Разберём небольшой пример.

Допустим, у нас есть интерфейс GreetingsService:

package org.acruxsource.sandbox.remoting.services;

public interface GreetingsService {
    String DEFAULT_NAME = "Mate";
    String greetings(String name);
}

На стороне приложения, предоставляющего сервисы для общего использования, пишем небольшую реализацию этого интерфейса:

package org.acruxsource.sandbox.remoting.services;

public class SimpleGreetingsService implements GreetingsService {

    @Override
    public String greetings(String name) {
        if(name == null || name.isEmpty())
            name = DEFAULT_NAME;
       
        return new StringBuilder("G'day, ").append(name).append("!").toString();
    }
}

Теперь можно заняться описанием компонентонентов Spring. Наш сервис:

И, собственно, его экспорт:

Вместо 1199 можно использовать любой другой не занятный порт. По умолчанию используется 1099.
Осталось указать сервис на стороне клиента:

Теперь данный сервис на стороне клиента можно использовать как обычные компоненты - использовать для поиска и внедрения зависимостей. Все вызовы к методам GreetingsService будут проксироваться классом RmiProxyFactoryBean.

В результате мы имеем приложение-сервер, предоставляющее сервисы и приложения-клиенты, которые могут использовать эти сервисы. Однако в данном случае есть некоторые нюансы: у RMI отсутствует поддержка использования сервисов через протокол HTTP (а надо ли?), RMI как протокол очень тяжеловесный (но надёжный) и используется только в схеме Java-to-Java, то есть и сервер и клиенты должны быть написаны на Java, или исполняться в JVM (не забываем про Groovy и другие JVM-языки).