Изменение интерфейсов SOAP и устаревшие веб-методы в java

моя команда разрабатывает уровень сервиса на java и графический интерфейс в dot-net, используя soap. Разработчики GUI продолжают расстраиваться, потому что уровень сервиса иногда меняет интерфейс веб-сервиса.

чтобы сохранить GUI chaps счастливым, а не разгромить оригинальные веб-методы, мы теперь пишем новые, которые живут рядом с существующими. Поскольку наш дизайн интерфейса soap все еще совершенствуется, это становится грязным, наверняка есть лучший способ! Любой предложения?

кроме того, бывают случаи, когда мы хотим осудить метод веб - службы-есть ли аннотация java для этого (та, которая будет отображаться в WSDL)?

Спасибо за любые предложения

1 ответов


нет такой аннотации устаревания, о которой я знаю. Это общий шаблон, который я обычно использую:

  • реализуйте SOAP api, помещая номер версии (v1) в имя WSDL или путь
  • написать новый (или улучшенный) код приложения, который заслуживает обновленного SOAP api
  • реализовать совершенно новую версию SOAP api с новым номером версии (v2) рядом с кодом v1, но при поддержке тех же классов домена
  • изменить реализация веб-службы v1 для выполнения миграции и (по возможности) вызова соответствующего метода службы v2
  • уведомить клиентов, что они должны начать использовать v2 вместо v1
  • ждать
  • Если вы находитесь в среде большого предприятия, подождите еще дольше ; -)
  • как только никто больше не использует v1 (проверьте это с помощью журналов и разговоров с пользователями), удалите интерфейс v1

этот подход работает только очень хорошо когда у вас есть хорошее разделение между кодом веб-службы и фактическим кодом приложения. Это помогает думать о коде веб-службы как о слое презентации.