Главная » Spring » Доступ к службам Hessian/Burlap Spring

0

Как было показано в разделе 11.2.2, клиент, пользующийся служ- бой Spitter с применением компонента RmiProxyFactoryBean, не имеет ни малейшего представления, что служба в действительности яв- ляется RMI-службой. На самом деле он вообще никак не связан с фактической реализацией удаленной службы. Единственное, с чем он имеет дело, – интерфейс SpitterService, а конкретные детали ре- ализации RMI-службы скрыты в настройках компонентов в конфи- гурационном файле Spring. Вся прелесть такой организации состоит в том, что из-за отсутствия в клиенте информации о фактической

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

Однако для любителей писать программный код на языке Java этот раздел станет полным разочарованием. Это обусловлено тем, что для внедрения в клиента службы Hessian вместо службы RMI до- статочно лишь заменить RmiProxyFactoryBean на HessianProxyFactoryBean. В настройках клиента службу spitter, реализованную на основе ре- шения Hessian, можно объявить, как показано ниже:

<bean id="spitterService" class="org.springframework.remoting.caucho.HessianProxyFactoryBean" p:serviceUrl="http://localhost:8080/Spitter/spitter.service" p:serviceInterface="com.habuma.spitter.service.SpitterService" />

Подобно настройкам службы RMI, свойство serviceInterface опреде- ляет интерфейс, реализованный службой, а свойство serviceUrl опре- деляет URL службы. Однако, поскольку решение Hessian основано на протоколе HTTP, в URL указывается протокол HTTP (определяется в настройках отображения адресов URL, выполненных выше). Схе- ма взаимодействий между клиентом и прокси-объектом, создаваемым компонентом HessianProxyFactoryBean, изображена на рис. 11.7.

Как оказывается, настройка внедрения службы Burlap в клиента также не содержит ничего интересного. Единственное отличие в том, что вместо HessianProxyFactoryBean используется BurlapProxyFactoryBean:

Рис. 11.7. Компоненты HessianProxyFactoryBean

и BurlapProxyFactoryBean создают прокси-объекты, обеспечивающие взаимодействие с удаленной службой по протоколу HTTP (Hessian – в двоичном формате, Burlap – в формате XML)

<bean id="spitterService" class="org.springframework.remoting.caucho.BurlapProxyFactoryBean" p:serviceUrl="http://localhost:8080/Spitter/spitter.service" p:serviceInterface="com.habuma.spitter.service.SpitterService" />

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

Поскольку решения Hessian и Burlap основаны на использова- нии протокола HTTP, им не свойственны проблемы с брандмауэра- ми, характерные для RMI. Однако RMI превосходит оба решения, Hessian и Burlap, когда дело доходит до сериализации объектов, передаваемых в RPC-сообщениях. Решения Hessian и Burlap ис- пользуют собственный механизм сериализации объектов, тогда как RMI использует механизм, встроенный в Java. При использовании сложных моделей данных, решения Hessian/Burlap могут оказаться недостаточно мощными.

Однако существует решение, заимствовавшее все самое лучшее из обеих технологий. В следующем разделе мы познакомимся с меха- низмом Spring HTTP Invoker, обеспечивающим возможность RPC по протоколу HTTP (как Hessian/Burlap) и в то же время исполь- зующим механизм сериализации объектов, встроенный в язык Java (как RMI).

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

По теме:

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