Нарешті, я збираюся виконати свою обіцянку і показати, від- куди береться WSDL-файл з визначенням веб-служби оцінки ком- бинации карт при грі в покер. У розділі 15.2.1 ми вже визначили формат представлення даних у вигляді схеми на мові XML Schema, в файлі PokerTypes.xsd. Перш ніж рушити далі, поверніться до лістингу 15.1, щоб освіжити в пам'яті, як виглядає определе- ня формату представлення даних.
Особливу увагу зверніть на імена, які я вибрав для XML-елементів, що визначають типи повідомлень для веб-служби: EvaluateHandRequest і EvaluateHandResponse. Ці імена були обрані
не випадково. Вони вибиралися цілеспрямовано, з урахуванням підтримки в Spring-WS принципу переваги угод перед Настроювання- ми, яка буде автоматично створювати WSDL-файл для служби оцінки комбінації карт.
Щоб задіяти цю підтримку, необхідно налаштувати спе- ціальний компонент DynamicWsdl11Definition.DynamicWsdl11Definition, який використовується сервлетом MessageDispatcherServlet для созда- ня WSDL -Визначення зі схеми на мові XML Schema. Це дуже зручно, так як у нас вже є схема XML Schema, що визначають щая формат представлення даних. Нижче показано, як я налаштував компонент DynamicWsdl11Definition в контексті Spring:
Компонент DynamicWsdl11Definition читає опис схеми на язи- ке XML Schema з файлу PokerTypes.xsd, як визначено властивістю schema. Він шукає в файлі все визначення елементів, оканчі- вающихся словом Request або Response. І виходячи з припущення, що ці закінчення відповідають повідомленням, що посилаються операци- ям служби або повертаються ними, створює відповідні еле- менти
Наприклад, обробляючи файл PokerTypes.xsd, компонент Dynamic- Wsdl11Definition передбачає, що елементи EvaluateHandRequest і EvaluateHandResponse описують входить і виходить повідомлення для операції з ім'ям EvaluateHand. В результаті він відтворює таке визначення WSDL:
Мал. 15.7. Компонент DynamicWsdl11Definition автоматично відтворює WSDL -визначення для веб-служби,
спираючись на опис схеми на мові XML Schema, визначальною повідомлення, якими клієнти обмінюються зі службою
Зверніть увагу, що компонент DynamicWsdl11Definition по- місце елемент
В даному випадку мається на увазі, що служба буде діяти на локальному комп'ютері, тому, якщо ви зберетеся випробувати її на віддаленому комп'ютері, вам доведеться змінити URL. Обра- титі увагу, що URL закінчується рядком / services в соответ- відно до настройками в елементі
Коль скоро ми заговорили про елемент
Тепер сервлет MessageDispatcherServlet зможе автоматично ге неріровать (за допомогою DynamicWsdl11Definition) визначення WSDL служби оцінки комбінації карт при грі в покер. Єдине питання, яке поки залишається без відповіді, - де шукати сгенеріро- ванне визначення WSDL.
Відповідь на це питання знаходиться в останньому пункті угоди, з яким слід MessageDispatcherServlet. Зверніть увагу, що я оголосив компонент DynamicWsdl11Definition з ідентифікатором poker. Коли компонент MessageDispatcherServlet отримає запит для URL
/poker.wsdl. він буде шукати в контексті Spring компонент з ім'ям poker, що створює визначення WSDL. В даному випадку він знайде компонент DynamicWsdl11Definition.
Використання зумовленого WSDL -Визначення
Компонент DynamicWsdl11Definition з успіхом можна використовувати в самих різних ситуаціях, так як він позбавляє від необхідності
писати WSDL -Визначення вручну. Але іноді може потребовать- ся більш повний контроль над WSDL -визначення служби. У таких ситуаціях буває бажано вручну створити WSDL-файл і потім впровадити його в контекст Spring за допомогою SimpleWsdl11Definition:
Компонент SimpleWsdl11Definition не генерує WSDL -определе- ня автоматично (рис. 15.9), він просто повертає WSDL-файл, ім'я якого вказується в властивості wsdl.
Мал. 15.9. Компонент SimpleWsdl11Definition просто повертає зумовлений WSDL-файл
Єдина проблема при використанні визначеного WSDL-файлу (крім зусиль, необхідних на його створення) - в тому, що він визначений статично. Це створює складності в тій частині WSDL -Визначення, де вказується місце розташування служби. На- приклад, погляньте на наступний (статичний) фрагмент WSDL:
Для цього досить додати параметр
розгортання служби
Отже, ми створили визначення служби, реалізували кінцеву точку і налаштували всі необхідні компоненти фреймворка Spring- WS. Зараз все готово до упаковки і розгортання веб-служби. Оскільки для управління проектом я вибрав інструмент Maven 2, створення WAR-файлу для подальшого розгортання зводиться до виконання простої команди:
% Mvn package deploy
Як тільки утиліта mvn завершить роботу, в цільовому каталозі по- з'явиться файл Poker-WS.war, який можна розгорнути на большін- стве серверів веб-додатків.
Приклад застосування фреймворка Spring-WS для створення веб-служби продемонстрував лише половину його можливостей. Дру раю його половина включає клієнтський API, який реалізує ту ж саму парадигму, засновану на обміні повідомленнями. Подивимося далі, як за допомогою Spring-WS створити клієнта, що використовує службу оцінки комбінації карт при грі в покер.