Изучаем Java EE 7 - [226]
>····
>······
>······
>······
>········org.agoncal.book.javaee7.chapter14.Validator
>······
>······
>········
>······
>····
>··
>
Упаковка
Веб-службы SOAP могут быть упакованы в файл с расширением. war или. jar (для EJB). Службы, упакованные в файл. war, могут использовать конечные точки-сервлеты или EJB Lite. Веб-службы, упакованные в файл. jar EJB, могут использовать только сессионные компоненты, не сохраняющие состояния, либо синглтоны.
Разработчик несет ответственность за упаковку таких элементов, как:
• реализация службы компонента и ее зависимые классы;
• интерфейсы конечной точки службы (не обязательно);
• файл WSDL либо путем включения, либо с помощью ссылки (не требуется, если используются аннотации, поскольку WSDL может быть автоматически сгенерирована средой выполнения JAX-WS);
• сгенерированные артефакты для запроса и ответа SOAP (не обязательно, поскольку они автоматически генерируются средой выполнения JAX-WS);
• опциональный дескриптор развертывания.
Публикация веб-служб SOAP
Как только веб-служба SOAP упакована, ее публикация — всего лишь вопрос развертывания архива в таком контейнере Java EE, как GlassFish или JBoss. Это потому, что JAX-WS является частью Java EE 7 и среда выполнения связана с сервером приложений. Но вы также можете опубликовать веб-службу SOAP в таком веб-контейнере, как Tomcat или Jetty, если встроите реализацию JAX-WS, например Metro, CXF или Axis2.
Но помните, что JAX-WS также поставляется в Java SE и иногда вам не потребуется подключать сервлеты или контейнер EJB (например, при тестировании веб-службы). В этом случае вы можете использовать API javax.xml.ws.Endpoint для программной публикации веб-службы SOAP. Метод Endpoint.publish (листинг 14.29) использует по умолчанию легкий сервер HTTP, который включен в Oracle JVM (определен в пакете com.sun.net.httpserver).
>@WebService
>public class CardValidator {
>··public boolean validate(CreditCard creditCard) {
>····// Бизнес-логика
>··}
>··public static void main(String[] args) {
>····Endpoint.publish("http://localhost:8080/cardValidator",
>·····················new CardValidator());
>··}
>}
В листинге 14.29 метод publish используется для публикации веб-службы SOAP CardValidator, после чего он начинает принимать входящие запросы по адресу http://localhost:8080/cardValidator. После этого можно вызывать методы вашей веб-службы. Существует также метод stop, который может быть использован для прекращения приема входящих запросов и отключения конечной точки (как вы увидите позже при разработке интеграционного теста).
Вызов веб-служб SOAP
До сих пор вы видели, как писать, упаковывать и публиковать веб-службы SOAP. Теперь рассмотрим, как их вызывать. С помощью WSDL и некоторых инструментов для создания заглушек клиентов Java (или прокси) вы можете легко вызвать веб-службы, не заботясь о соединении их с HTTP или SOAP. Вызов веб-службы похож на вызов распределенных объектов с помощью RMI. Как и RMI, JAX-WS позволяет программисту использовать локальный вызов метода для вызова распределенной службы. Разница заключается в том, что на удаленном узле веб-служба может быть написана на другом языке программирования (обратите внимание, что вы можете также вызвать код, написанный не на Java, с применением RMI–IIOP). WSDL является стандартным контрактом между потребителем и службой. Metro предоставляет инструмент преобразования WSDL в Java (wsimport), который генерирует Java-интерфейсы и классы из WSDL. Такие прокси дают вам Java-представление конечной точки веб-службы (сервлет или EJB). Этот прокси затем перенаправляет локальный вызов Java удаленной веб-службе, используя HTTP.
Когда с помощью такого прокси вызывается метод (рис. 14.5), он преобразует параметры метода в сообщения SOAP (запрос) и отправляет их конечной точке веб-службы. Чтобы получить результат, ответ SOAP преобразуется обратно в экземпляр возвращаемого типа. Вам не нужно понимать внутреннюю работу прокси и даже смотреть на его код. Перед компиляцией вашего клиента-потребителя нужно сгенерировать SEI, чтобы получить прокси-класс, который можно вызывать в коде.
Рис. 14.5. Потребитель, вызывающий веб-службу с помощью прокси
При разработке потребителей SOAP с использованием нисходящего подхода клиент должен получить WSDL, создать необходимые артефакты, вызвать веб-службу CardValidator для проверки кредитной карты (SOAP-сообщение validate) и получить ответ (SOAP-сообщение validateResponse).
Инструменты wsimport и wsgen поставляются в JDK 1.7, а также GlassFish или Metro. wsimport в качестве входного аргумента принимает WSDL и формирует такие артефакты JAX-WS, как SEI; wsgen читает класс конечной точки веб-службы и генерирует WSDL. Вы можете получить доступ к этим инструментам непосредственно после установки Java SE 7 либо с помощью интерфейса командной строки (CLI) GlassFish, задачи Ant или плагина Maven.
