Изучаем Java EE 7 - [219]
Web Services 1.3
JSR 109 определяет модель программирования и поведение во время выполнения веб-служб в контейнере Java EE. Он также определяет упаковку для обеспечения переносимости веб-служб на разные реализации серверов.
WS-Metadata 2.3
Web Services Metadata (WS-Metadata, спецификации JSR 181) предоставляет аннотации, помогающие определять и развертывать веб-службы (основные пакеты перечислены в табл. 14.5). Основная цель JSR 181 — упростить развитие веб-служб. Он обеспечивает отображение объектов между WSDL и интерфейсами Java и наоборот, что достигается благодаря аннотациям. Эти аннотации могут быть использованы в простых классах Java или EJB.
| Пакет | Описание |
|---|---|
| javax.jws | Содержит аннотации для перехода от Java к WSDL |
| javax.jws.soap | API, предназначенные для преобразования веб-служб к протоколу сообщений SOAP |
Что нового в спецификации веб-служб SOAP
К сожалению, ничего нового не появилось в JAX-WS и WS-Metadata в Java EE 7. Спецификации веб-служб SOAP не были обновлены в этой версии Java EE. Например, в Java EE 7 веб-службы SOAP не используются управляемыми компонентами, поэтому вы не можете задействовать перехватчики, связывание перехватчиков, внедрение контекста и т. д. Bean Validation также не был интегрирован, то есть вы не можете выполнить проверку на уровне метода (см. главу 3).
Примеры реализаций
Metro — это пример реализации спецификаций веб-служб Java с открытым исходным кодом. Он состоит из JAX-WS и JAXB, а также поддерживает устаревшие API JAX-RPC. Он позволяет создавать и развертывать безопасные, надежные, транзакционные, совместимые с SOAP веб-службы, а также потребители веб-служб SOAP. Metro создается сообществом GlassFish, но может быть использован и вне GlassFish, в среде Java SE или других веб-контейнерах (например, Tomcat или Jetty).
Apache CXF (ранее известный как XFire) и Apache Axis2 также реализуют стек JWS. Кроме того, не являясь примерами реализации, оба фреймворка также активно используются в веб-службах SOAP.
Создание веб-служб SOAP
До сих пор мы рассмотрели много низкоуровневых понятий, таких как протокол HTTP, документы WSDL, сообщения SOAP или XML. Но как создать веб-службу SOAP с помощью всех этих спецификаций? Вы можете либо начать с WSDL, либо сразу перейти к кодированию на Java.
Поскольку документ WSDL — это контракт между потребителем и службой, он может быть использован для создания кода Java для потребителя и для службы. Этот подход называется нисходящим, также известным как «сначала контракт». Он начинается с создания контракта (WSDL) путем определения операций, сообщений и т. д. Когда потребитель и поставщик договорились о контракте, можно реализовывать классы Java на основе этого договора. Metro предоставляет некоторые инструменты (wsimport), позволяющие создать классы на базе WSDL.
При другом подходе — восходящем — реализация класса уже существует и нужно лишь создать WSDL. Опять же Metro предоставляет утилиты (wsgen) для генерации WSDL из существующих классов. В обоих случаях код, возможно, должен быть скорректирован в соответствии с WSDL и наоборот. В этой ситуации приходит на помощь JAX-WS. Благодаря простой модели развития и нескольким аннотациям преобразования Java к WSDL могут быть скорректированы. Но будьте осторожны: восходящий подход может привести к созданию очень неэффективных приложений, поскольку методы и классы Java не имеют никакого отношения к идеальной детализации сообщений, перемещающихся по сети. Если имеют место высокая задержка и/или низкая пропускная способность, следует посылать меньшее количество более крупных сообщений, и это может быть более эффективно выполнено при использовании первого подхода.
Несмотря на все эти спецификации, концепции, стандарты и организации, написание и использование веб-служб с применением нисходящего подхода очень легко реализуется. Веб-службы SOAP следуют парадигме Java EE 7 «простота разработки» и не требуют от вас писать WSDL или SOAP. Веб-службы — это просто аннотированный POJO, который должен быть развернут в контейнере веб-службы. В листинге 14.5 показан код веб-службы, которая проверяет кредитную карту.
>@WebService
>public class CardValidator {
>··public boolean validate(CreditCard creditCard) {
>····Character lastDigit = creditCard.getNumber(). charAt(
>··························creditCard.getNumber(). length() — 1);
>····if (Integer.parseInt(lastDigit.toString()) % 2!= 0) {
>······return true;
>····} else {
>······return false;
>····}
>··}
>}
Как и сущности или EJB, веб-службы SOAP используют модель аннотированного POJO, который следует политике конфигурации с помощью исключений. Это означает, что веб-служба может быть простым классом Java, который имеет аннотацию @javax.jws.WebService, если все значения по умолчанию вам подходят. Тогда среда выполнения JAX-WS сгенерирует код, необходимый для преобразования вызова метода Java в XML, который отправляется через HTTP. Эта веб-служба SOAP CardValidator имеет один метод, предназначенный для проверки кредитной карты. Он принимает в качестве параметра информацию о кредитной карте и возвращает двоичное значение в зависимости от того, действительна карта или нет. В этом примере он предполагает, что кредитные карты с четным номером действительны, а карты с нечетным — нет.
