Главная » Spring » Механизм RPC, основанный на сообщениях, в Lingo Spring

0

Lingo1 – это механизм удаленных взаимодействий, основанный на фреймворке Spring и напоминающий механизм JMS Invoker в Spring. Фактически в документации Javadoc с описанием классов JMS Invoker библиотека Lingo упоминается косвенно, как образец для подражания2.

В отличие от JMS Invoker, библиотека Lingo способна в пол- ной мере использовать асинхронную природу JMS для обращения к службам. Это означает, что на момент, когда клиент производит вызов, сервер вообще может быть недоступным. Более того, при взаимодействии со службой, выполняющей длительные операции, клиент может не ждать их завершения.

1   http://lingo.codehaus.org.

2   Библиотека Lingo не упоминается напрямую, зато упоминается ее автор, Джеймс Страхан (James Strachan).

В отличие от других механизмов удаленных взаимодействий, об- суждавшихся в главе 11, и от механизма JMS Invoker, библиотека Lingo не входит в состав фреймворка Spring Framework. Это отдель- ный проект, опирающийся на использование экспортера JMS-служб и клиентского прокси-объекта.

Наше знакомство с библиотекой Lingo мы начнем с обзора биб- лиотечного класса JmsServiceExporter, используемого для экспортиро- вания служб. Затем мы рассмотрим приемы доступа к этим службам с помощью библиотечного класса JmsServiceProxy.

Экспортирование асинхронной службы

Как показано в следующем объявлении, компоненты JmsService- Exporter и JmsInvokerServiceExporter настраиваются практически оди- наково:

<bean  id="alertServiceExporter" class="org.logicblaze.lingo.jms.JmsServiceExporter" p:connectionFactory-ref="connectionFactory" p:destination-ref="alertServiceQueue"

p:service-ref="alertService" p:serviceInterface="com.habuma.spitter.alerts.AlertService"  />

Свойства service и serviceInterface в точности соответствуют од- ноименным свойствам компонента JmsInvokerServiceExporter. Одна- ко компонент JmsServiceExporter имеет новое свойство. Компонент JmsServiceExporter не может использоваться как обработчик сообще- ний в контейнере обработчиков, поэтому ему нужно передать ссыл- ки на фабрику соединений JMS и приемник сообщений в свойствах connectionFactory  и destination.

Обратите внимание, что свойство destination имеет тип javax.jms. Destination. По этой причине в него должна внедряться ссылка на компонент-приемник. Следующий компонент alertServiceQueue будет играть роль приемника JMS RPC-сообщений, передаваемых в оче- редь с именем spittle.alert.queue:

<amq:queue id="alertServiceQueue"

physicalName="spitter.alert.queue" />

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

библиотеке, если фреймворк Spring имеет собственный механизм JMS RPC, предоставляющий те же самые возможности.

Но не спешите с выводами. Как демонстрируется чуть ниже, на стороне клиента библиотека Lingo предлагает кое-что, чего не может предложить JMS Invoker: асинхронные обращения к службе.

Доступ к асинхронной службе

При вызове методов прокси-объекта JmsInvokerServiceProxy, соз- данного фреймворком Spring, приложение вынуждено ждать. Даже несмотря на то что в качестве транспорта используется JMS, прокси- объект будет ждать получения ответа от службы.

Компонент JmsProxyFactoryBean, создаваемый библиотекой Lingo, напротив, может быть настроен на выполнение операций в асин- хронном режиме. Например, клиент службы извещений, реализо- ванный на основе библиотеки Lingo, можно настроить, как показано ниже:

<bean  id="alertService" class="org.logicblaze.lingo.jms.JmsProxyFactoryBean" p:connectionFactory-ref="connectionFactory" p:destination-ref="queue"

p:serviceInterface="com.habuma.spitter.alerts.AlertService">

<property name="metadataStrategy">

<bean  id="metadataStrategy" class="org.logicblaze.lingo.SimpleMetadataStrategy">

<constructor-arg   value="true"/>

</bean>

</property>

</bean>

Свойства connectionFactory,  destination  и  serviceInterface  играют ту же роль, что и в предыдущих примерах. Новым здесь является свойство metadataStrategy, значением которого является внутренний компонент типа SimpleMetadataStrategy.

Кроме всего прочего, свойство metadataStrategy определяет, какие методы должны действовать в асинхронном режиме. Единственной доступной реализацией является класс SimpleMetadataStrategy, кон- структор которого может принимать единственный логический ар- гумент, определяющий, должны ли все методы, не имеющие возвра- щаемого значения, действовать асинхронно. В данном случае кон- структору передается значение true, указывающее, что все методы

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

Если передать конструктору значение false или вообще исклю- чить определение свойства metadataStrategy из объявления компо- нента JmsProxyFactoryBean, все методы обращения к службе будут действовать синхронно, а компонент JmsProxyFactoryBean превратится практически в полный аналог компонента JmsInvokerServiceProxy.

В заключение

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

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

В этой главе мы познакомились с несколькими способами орга- низации асинхронных взаимодействий между двумя приложениями, осуществляемых с помощью Spring посредством брокеров сообще- ний и JMS. Шаблон JMS в Spring позволяет избежать шаблонного кода, который обычно приходится писать при использовании тра- диционной программной модели JMS. А управляемые сообщениями компоненты в Spring дают возможность объявлять методы, вызы- ваемые автоматически при появлении новых сообщений в очереди или в теме.

Кроме того, здесь был рассмотрен пример применения механизма JMS Invoker, реализованного в Spring, а также библиотеки Lingo, обеспечивающих RPC на основе сообщений с помощью компонен- тов Spring. Несмотря на то что механизм JMS Invoker в Spring был создан по образу и подобию библиотеки Lingo и может служить ее заменой, он поддерживает только синхронные взаимодействия. Библиотека Lingo, в свою очередь, предлагает дополнительные особен- ности, недоступные в JMS Invoker: возможность вызывать удален- ные методы асинхронно.

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

По теме:

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