Главная » Spring » Использование поддержки шлюза веб-служб Spring

0

Как рассказывалось в главе 8 (см. разделы 8.3.3, 8.4.3, 8.5.3 и 8.6.2), API доступа к данным в Spring включает ряд вспомогатель- ных классов, предоставляющих шаблоны, которые не требуется настраивать. В Spring-WS имеется аналогичный класс поддержки WebServiceGatewaySupport, который автоматически предоставляет сво- им наследникам доступ к объекту WebServiceTemplate.

В листинге 15.7 демонстрируется окончательная реализация ин- терфейса PokerClient, класс PokerServiceGateway, наследующий класс WebServiceGatewaySupport.

Листинг 15.7. Класс WebServiceGatewaySupport предоставляет доступ к объекту WebServiceTemplate посредством метода getWebServiceTemplate()

package com.springinaction.ws.client; import  java.io.IOException;

import     org.springframework.ws.client.core.support.WebServiceGatewaySupport; import  com.springinaction.poker.Card;

import   com.springinaction.poker.PokerHandType;

import      com.springinaction.poker.webservice.EvaluateHandRequest; import     com.springinaction.poker.webservice.EvaluateHandResponse;

public class PokerServiceGateway         // Наследует WebServiceGatewaySupport extends  WebServiceGatewaySupport

implements   PokerClient   {

public  PokerHandType  evaluateHand(Card[]  cards) throws IOException {

EvaluateHandRequest request = new EvaluateHandRequest(); request.setHand(cards);

// Использовать предоставленный объект WebServiceTemplate EvaluateHandResponse response = (EvaluateHandResponse)

getWebServiceTemplate().marshalSendAndReceive(request);

return  response.getPokerHand();

}

}

Как видите, класс PokerServiceGateway мало отличается от клас- са MarshallingPokerClient. Основное отличие заключется в том, что PokerServiceGateway не требует внедрения компонента WebService- Template. Вместо этого он получает экземпляр WebServiceTemplate вы- зовом метода getWebServiceTemplate(). За кулисами WebServiceGateway- Support создает объект WebServiceTemplate без необходимости явно определять его в контексте Spring.

Даже при том, что больше не требуется явно определять ком- понент WebServiceTemplate в Spring, параметры создания экземпляра WebServiceTemplate все еще необходимо определять, но уже в виде свойств компонента WebServiceGatewaySupport. В случае использования

класса PokerServiceGateway это означает, что необходимо настроить свойства messageFactory, messageSender, marshaller  и unmarshaller:

<bean id="pokerClientGateway" class="com.springinaction.ws.client.PokerServiceGateway">

<property   name="messageFactory">

<bean    class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory"/>

</property>

<property name="messageSender" ref="messageSender"/>

<property name="marshaller" ref="marshaller" />

<property name="unmarshaller" ref="marshaller" />

</bean>

Обратите внимание, что свойствам присваиваются те же значе- ния, что присваивались одноименным свойствам компонента Web- ServiceTemplate.

В заключение

Традиционно веб-службы рассматриваются как еще один способ организации удаленных взаимодействий. В действительности мно- гие разработчики любовно называют их как «CORBA через XML».

Проблема применения веб-служб для организации удаленных взаимодействий обусловлена тем, что они влекут за собой образо- вание тесной связи между службой и клиентами. Клиент оказывает- ся накрепко привязанным к внутреннему API службы. А определе- ние службы – это лишь побочный эффект такой связи. Изменения в службе могут вступить в противоречие с реализацией клиента, что потребует его изменения или поддержки нескольких версий службы.

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

«contract-first», поскольку в нем обслуживание строится на основе определения веб-службы. В отличие от простых удаленных объек- тов, веб-службы в модели «contract-first» реализуются как конечные точки, обрабатывающие сообщения, структура которых описывается определением службы. Как следствие служба и ее API могут изме- няться, не нарушая определения.

Spring-WS – замечательный фреймворк для создания веб-служб в модели «contract-first». Опираясь на Spring MVC, конечные точки Spring-WS обрабатывают XML-сообщения, полученные от клиента, и также генерируют в ответ XML-сообщения.

Если по складу характера вы похожи на меня, то наверняка весьма скептически восприняли всю проделанную выше работу по организации веб-службы с применением фреймворка Spring-WS. Не буду отрицать, что я в свое время отклонил модель «contract- first» создания веб-служб как требующую значительных усилий для SOAP-ифизации компонентов в сравнении с технологией JAX-WS, использующей модель «contract-last». Фактически, когда я впервые столкнулся с фреймворком Spring-WS, я отодвинул его в сторону как требующий слишком много работы и не обладающий явными преимуществами… какая глупость!

Но, немного поразмыслив, я понял, что преимущество слабой связанности определения службы с внутренним API легко переве- шивает дополнительные усилия, которые требуется приложить при использовании Spring-WS. И эти усилия окупятся сторицей, так как в результате мы получаем возможность изменять и улучшать внут- ренний API приложения, не беспокоясь о нарушении договоренно- стей с клиентами, оформленными в виде определения.

В следующей главе мы увидим столкновение двух миров – под- держку использования существующих и разработки новых компо- нентов Enterprise JavaBeans.

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

По теме:

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