Главная » Spring » Введение в Spring-WS

0

Фреймворк Spring Web Services (или Spring-WS) – один из про- ектов, развивающихся в рамках Spring, целью которого является создание веб-служб на основе модели «contract-first». Что же это за модель «contract-first»? Ответить на этот вопрос будет проще, если сначала рассмотреть противоположную ей модель организации веб-служб: «contact-last».

В главе 11 (см. раздел 11.5.1) мы использовали JAX-WS для экс- портирования компонентов как удаленных веб-служб. Сначала мы написали программный код на языке Java (реализацию службы). За- тем определили соответствующий компонент в конфигурации Spring. И наконец, воспользовались классом SimpleJaxWsServiceExporter, что- бы превратить его в веб-службу. Мы не объявляли явно определение службы (WSDL и XSD). Механизм JAX-WS автоматически гене- рирует это определение после развертывания службы. Проще гово- ря, определение веб-службы создавалось в последнюю очередь, что в точности соответствует значению названия «contract-last».

Модель «contract-last» разработки веб-служб пользуется большой популярностью по одной основной причине: простота. Большинство разработчиков не обладают стойкостью духа, необходимой для ос- воения WSDL, SOAP и XML Schema (XSD). В модели «contract- last» нет необходимости разбираться со сложными файлами WSDL и XSD. Достаточно лишь написать Java-класс, реализующий службу, и попросить фреймворк «SOAP-ифизировать» его. Если фреймворк, такой JAX-WS, способен решить эту проблему, зачем тогда нам бес- покоиться о ней?

Но есть одна маленькая проблема: при использовании модели разработки веб-службы «contract-last»  ее  определение  является прямым отражением внутреннего API приложения. Как правило, внутренний API приложения является намного более изменчивым, чем допустимо для внешнего API. А при использовании модели

«contract-last» изменение внутреннего API влечет за собой измене- ние определения службы, что в конечном итоге может потребовать внести изменения в клиентские приложения, пользующиеся служ-

бой. Даже простой рефакторинг, выполненный сегодня, может при- вести к изменению определения службы завтра.

Все это приводит к классической проблеме поддержки несколь- ких версий веб-служб. Беда в том, что изменить определение службы намного проще, чем изменить реализацию клиентов, использующих эту службу. Если веб-службой пользуются 1000 клиентов, то после изменения определения службы 1000 клиентов окажутся неработо- способны, пока не будут изменены в соответствии с новым опре- делением. Типичное решение этой проблемы состоит в том, чтобы поддерживать несколько версий службы, пока все клиенты не будут обновлены. Однако это многократно увеличивает стоимость обслу- живания и поддержки, так как вы вынуждены будете поддерживать несколько версий одной и той же службы.

Гораздо проще стараться избегать изменения определения служ- бы. А когда такие изменения необходимы, они не должны нарушать совместимость с предыдущими версиями. Но этого сложно добить- ся, когда определение службы генерируется автоматически.

Проще говоря, проблема в том, что в модели «contract-last» са- мый важный элемент, определение службы, интерпретируется как нечто второстепенное. Основное внимание в этой модели уделяется особенностям реализации веб-службы, а не тому, что она должна делать.

Решение данной проблемы состоит в том, чтобы перевернуть все с головы на ноги – создать сначала определение веб-службы, а за- тем решать вопросы реализации. Такая модель разработки называ- ется «contract-first». Определение веб-службы составляется почти без учета, как должно выглядеть приложение, реализующее его. Это достаточно практично, потому что такой подход подчеркивает – что ожидается от службы, а не как она должна быть реализована.

Что? Почувствовали себя некомфортно. Может быть, вы съели на обед необычно большой буритто… или, может быть, вас испугала необходимость писать WSDL-файл вручную?

Не волнуйтесь. Я не настолько бесчеловечен, как могло пока- заться. В процессе повествования я познакомлю вас с некоторыми приемами, упрощающими определение службы. (Если вам не стало легче, советую принять антацидное средство и в будущем сократить в своем рационе количество острых блюд.)

Основной рецепт разработки веб-служб с использованием моде- ли «contract-first» и на основе фреймворка Spring-WS представлен в табл. 15.1.

Таблица 15.1. Этапы разработки веб-службы в модели «contract- first»

Этап

Действие

Описание

1

Составить определение службы

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

WSDL-файла

2

Написать конечную точку службы

На этой стадии создаются классы, принимающие и обрабатывающие сообщения, отправляемые веб-службе

3

Настроить конечную точку и инфраструктуру Spring-WS

На этой стадии производится связывание конечной точки веб-службы и компонентов Spring-WS

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

Рис. 15.1. Служба оценки комбинации карт при игре в покер.

Службе передается комбинация из пяти карт, а она определяет их значение при игре в покер

Поскольку разработка ведется с использованием модели «contract- first», первое, что следует сделать, – создать определение службы. Начнем.

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

По теме:

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