Статьи

Вы действительно понимаете @WebService?

Апрель 21, 2018

Веб-сервисы SOAP никоим образом не являются передовыми технологиями — хотя веб-сервисы на основе REST все еще имеют место, они предлагают жесткую конкуренцию. Во всяком случае — это определенно не сообщение REST vs SOAP!
Я наблюдал несколько случаев, когда веб-службы SOAP на основе Java использовались не совсем идеально, если не сказать больше. Я думаю, что это связано с отсутствием понимания в отношении некоторых основ JAX-WS (спецификация Java EE для веб-служб на основе SOAP) в целом.

В этом посте упоминаются довольно простые вещи, связанные с веб-сервисами на основе SOAP, созданными с использованием JAX-WS. Некоторые из обсуждаемых вопросов:

  • каков жизненный цикл аннотированного POJO @WebService?
  • это потокобезопасно? что произойдет, если на ваш веб-сервис будут запущены параллельные запросы клиентов?

Аннотация @WebService

Технически говоря, аннотация @WebService — это все, что вам нужно, чтобы превратить POJO в конечную точку SOAP. Неудивительно, что это все, что мы обычно делаем — аннотируем наш класс с помощью @WebService и некоторых других вспомогательных аннотаций, таких как @WebMethod, @WebParam и т. Д., Разворачиваем WAR, запускаем SoapUI , запускаем несколько тестов и наслаждаемся славой!

Что нужно знать о POJO, аннотированных @WebService

  • POJO, аннотированный с помощью @WebService, развернутого в WAR , обслуживается веб-контейнером (это важно)
  • Жизненный цикл — один экземпляр POJO обслуживает запросы от клиента. Очень похоже на сервлеты.
  • Аспект параллелизма (безопасность потоков) — они не безопасны для потоков . Один и тот же экземпляр компонента может одновременно использоваться несколькими потоками . Хотя это не проблема, если ваша служба не имеет состояния, то есть не использует переменные экземпляра для хранения состояния — вы все равно можете столкнуться с проблемами масштабируемости (в конце концов, это всего лишь один экземпляр!). Если ваш POJO использует переменные экземпляра для хранения состояния, то вы находитесь в большом супе и, безусловно, столкнетесь с проблемами, связанными с непоследовательным поведением, возникающим в результате одновременного доступа потоков к одному экземпляру вашего класса веб-сервисов.
01
02
03
04
05
06
07
08
09
10
// is this robust enough ?
 
@WebService
public class POJO_WS{
    @WebMethod
    public String getDate(){
        System.out.println("hashCode -- "+ this.hashCode());
        return new Date().toString();
    }
}

Идеально говоря. , ,

  • нужно сделать веб-сервисы не имеющими состояния — запускать и забывать стиль. Не храните состояние внутри переменных экземпляра
  • если вы решили использовать переменные экземпляра — убедитесь, что вы как разработчик, кодируете свой веб-сервис потокобезопасным способом . Здесь есть несколько вариантов, некоторые из которых включают использование старой доброй синхронизированной (хотя и далеко не идеальной!), Поточно-безопасной коллекции (ConcurrentHashMap) и т.д.
  • лучшее решение IMO — если вы используете сервер приложений, совместимый с Java EE (например, Weblogic), вы должны неизменно развертывать свои веб-сервисы как EJB (я не буду вдаваться в подробности EJB здесь! Вы можете сослаться на мои предыдущие посты если интересно).
  • Что вы получите от этого? (1) EJB по умолчанию являются потокобезопасными . Вам не нужно беспокоиться о параллельном кодировании и безопасности потоков как части вашей бизнес-логики — вы получаете это бесплатно! (2) EJB-компоненты — это объединенные компоненты . Контейнер кэширует экземпляры в памяти и выделяет их клиентам в соответствии с запросом. Масштабируемость бесплатно ( примечание — конфигурации пула EJB зависят от контейнера, и каждый сервер определяет конкретный способ достижения этого) (3) EJB по умолчанию являются транснациональными — в случае, если вы обращаетесь к внутренним базам данных как часть логики веб-службы EJB идеальны (детали транзакций лучше всего разбираются парнем, который действительно глубоко их понимает! Я не собираюсь смущать себя, пытаясь вести себя так, как будто я знаю их от начала до конца)
  • Как «накачать» мой веб-сервис? (1) Просто используйте аннотацию @Stateless — это превращает ваш простой POJO в полноценный EJB, который теперь может пользоваться всеми контейнерными сервисами (2) развертывать ваш веб-сервис не как WAR, а как EJB-JAR, упакованный в EAR , Это гарантирует, что контейнер EJB захватит ваш POJO и сплетет всю магию, которой я хвастался!
01
02
03
04
05
06
07
08
09
10
11
//not perfect - but better than just @WebService
//will recieve free services from the EJB container, courtsey @Stateless !
 
@Stateless
@WebService
public class POJO_EJB_and_SOAP {
    public String fetchDate(){
        System.out.println("hashCode -- "+ this.hashCode());
        return new Date().toString();
    }
}

тестирование

Я не эксперт по тестированию, но такие инструменты, как JMeter, могут сделать меня умным! Сделайте себе одолжение и используйте JMeter, чтобы упростить процесс тестирования веб-службы SOAP. Это не так сложно. Тривиальный пример ниже

pojo_ws

Перспектива клиента

  • Что касается создания заглушек из существующего WSDL, я бы определенно выбрал стандартную возможность в самой Java SE . Я просто констатирую это, потому что это работало для меня безупречно в прошлом, вместо того, чтобы попробовать другие реализации, такие как Axis 2 или Apache CXF.
  • Я не хочу их подрывать, но не вижу смысла тратить время на изучение других вещей, когда в самом JDK есть хорошо документированный стандартный инструмент! Просто перейдите в JAVA_HOME / bin , найдите команду wsimport и получите взлом.
  • Большинство IDE, которые предоставляют возможность создания заглушек, используют этот инструмент

Это была просто быстрая разглагольствование! Надеюсь, это имело смысл

Ура!

Ссылка: Вы действительно понимаете @WebService? от нашего партнера JCG Абхишека Гупты в блоге Object Oriented ..
61
Share: