Главная » Spring » Обзор механизмов удаленных взаимодействий в Spring

0

Удаленное взаимодействие – это диалог между клиентским при- ложением и службой. На стороне клиента востребованы некоторые функциональные возможности, не входящие в компетенцию при- ложения. Поэтому приложение обращается к другой системе, спо- собной предоставить необходимую функциональность. Удаленное приложение обеспечивает доступ к своей функциональности по- средством удаленной службы.

Представьте, что нам захотелось обеспечить доступ к некоторым функциям приложения Spitter как к удаленным службам для ис- пользования другими приложениями. Например, обычными или мо- бильными приложениями, реализующими интерфейс к приложению Spitter, в дополнение к веб-интерфейсу, как показано на рис. 11.1. Для этого необходимо предоставить доступ к базовым функциям интерфейса SpitterService, реализованного в виде удаленной службы.

Диалог между другими приложениями и приложением Spitter начинается с вызова удаленной процедуры (Remote Procedure Call, RPC) в клиентском приложении. На первый взгляд, RPC напоми- нает вызов метода локального объекта. Оба вызова являются син- хронными операциями и блокируют дальнейшее выполнение про- граммы, пока вызов процедуры не завершится.

Рис. 11.1. Сторонний клиент может взаимодействовать с приложением Spitter, выполняя удаленные вызовы экспортированных методов

Здесь можно провести аналогию с общением между двумя людь- ми. Если вы обсуждаете на работе итоги футбольного матча, состо- явшегося в выходные, следовательно, вы участвуете в локальном диалоге – диалоге между двумя людьми, находящимися в одной комнате. Аналогично вызов локального метода является переходом потока выполнения из одного блока кода в другой внутри одного приложения.

С другой стороны, если вы поднимаете телефонную трубку, чтобы позвонить клиенту в другой город, вы будете участвовать в удален- ном диалоге через сеть телефонных проводов. Аналогично, когда выполняется вызов удаленной процедуры, управление выполнением передается от одного приложения другому, теоретически выполняю- щемуся на другом компьютере, через компьютерную сеть.

Фреймворк Spring поддерживает несколько моделей RPC, вклю- чая вызов удаленных методов (Remote Method Invocation, RMI), Caucho Hessian и Burlap, а также Spring HTTP Invoker. Все эти модели перечислены в табл. 11.1, где также коротко описываются ситуации, где они могут пригодиться.

Независимо от выбранной модели удаленных взаимодействий все проблемы их использования упираются в поддержку их фреймвор- ком Spring. Это означает, что, научившись настраивать Spring для работы с одной моделью, вам почти не придется изучать ничего но- вого, чтобы задействовать другую модель.

При использовании любой модели, службы в приложении мож- но настраивать как компоненты, управляемые фреймворком Spring. Это достигается за счет применения фабричного компонента, созда- ющего прокси-объекты, позволяющие связывать удаленные службы со свойствами компонентов, как если бы они были локальными объ- ектами. Как это делается, показано на рис. 11.2.

Таблица 11.1. Spring поддерживает RPC посредством нескольких технологий удаленных взаимодействий

Модель RPC

Может использоваться для…

Вызов удаленных методов (Remote Method Invocation, RMI)

Доступа к службам, реализованным на языке Java,

а также для реализации таких служб, когда отсутству- ют сетевые ограничения, такие как брандмауэры

Hessian или Burlap

Доступа к службам, реализованным на языке Java, посредством протокола HTTP, а также для реализации таких служб, когда отсутствуют сетевые ограничения, такие как брандмауэры

HTTP Invoker

Доступа к службам, реализованным на основе фреймворка Spring, а также для реализации таких служб, когда имеются какие-либо сетевые ограни- чения и когда желательно использовать механизмы сериализации Java в формат XML или другие частные форматы

JAX-RPC и JAX-WS

Доступа к платформонезависимым веб-службам посредством протокола SOAP, а также для реализации таких служб

Рис. 11.2. В Spring обращение к удаленным службам выполняется через прокси-объекты, ссылки на которые можно внедрить в программный код клиента, как если бы эти службы были обычными компонентами Spring

Клиент обращается к прокси-объекту, как если бы он реализовал функциональность службы. Прокси-объект взаимодействует с уда- ленной службой от имени клиента. Он реализует все операции по установлению соединения и выполнению вызовов методов удален- ной службы.

К тому же, если результатом обращения к удаленной службе является исключение java.rmi.RemoteException, прокси-объект обра-

ботает его и возбудит неконтролируемое исключение RemoteAccess- Exception. Удаленные исключения обычно сигнализируют о проб- лемах с сетью или с настройками, которые сложно обработать на стороне клиента. Поскольку в распоряжении клиента не так много вариантов обработки удаленных исключений, возбуждение исключения RemoteAccessException на стороне клиента не является обязательным.

На стороне службы имеется возможность экспортировать функ- циональность любого компонента с использованием любой модели из перечисленных в табл. 11.1. На рис. 11.3 показано, как объект- экспортер экспортирует методы компонента в виде API удаленной службы.

Рис. 11.3. Компоненты, выполняющиеся под управлением Spring, могут экспортироваться как удаленные службы

с использованием шлюзов удаленных взаимодействий

И реализация взаимодействий с удаленными службами, и реа- лизация самих удаленных служб в Spring в значительной степени является проблемой конфигурирования. Вам не придется писать программный код, реализующий удаленные взаимодействия. При реализации компонентов вам не придется беспокоиться о поддерж- ке RPC (однако все компоненты, передаваемые в удаленные вызовы или возвращаемые ими, в обязательном порядке должны реализо- вать  интерфейс  java.io.Serializable).

Начнем с исследования поддержки в Spring удаленных взаимо- действий в модели RMI – оригинальной для Java технологии уда- ленных взаимодействий.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии