JAX-WS обслуживание и клиентское управление версиями

Question

Моя группа впервые попадает в веб-службы. Каким образом можно управлять проблемами версий с помощью веб-сервисов и клиентов? Мы создаем наши сервисы и клиенты, использующие в RAD IBM, с помощью мастеров, которые он представляет. Службы и клиенты работают достаточно хорошо, но нам интересно, как управление ими станет задачей в будущем.

-Если сервис меняется, и интерфейс не меняется, я полагаю, что старые клиенты никогда не узнают разницу и будут работать нормально.

-Если служба изменит добавление нового свойства в параметр, будут ли старые клиенты работать с ним, если им не нужно устанавливать это значение?

-Как люди обрабатывают контроль версий веб-сервисов по мере их роста, а число приложений, использующих их клиентов, растет? Что лучше всего подходит для такого рода вещей?

Answer 1

Существует два типа версий, которые мы используем. Тот, который видим для клиентов (общедоступных), и тот, который не является (закрытым). Это происходит от того, что вы уже затронули, зависят ли клиенты или нет.

Если на клиентов влияет, например, изменение определений схемы XSD или функциональных возможностей WS-изменений таким образом, что клиенты также должны изменить их конец, мы меняем общедоступную версию. Мы увеличиваем номер версии в корневом контексте WS, что означает, что у нее будет другой URL-адрес, чем предыдущая. Также убедитесь, что архив кода, в нашем случае это война, также имеет общедоступную версию, чтобы не перезаписывать предыдущее развертывание.

Например, наш WS называется foo в общедоступной версии 2. Его URL-адрес: http://ourserver:8000/foo_2, а файл войны называется foo_2. Мы изменили нашу схему XSD, поэтому клиенты должны реагировать на изменение. Мы обновляем версию и теперь URL-адрес: http://ourserver:8000/foo_3, а файл войны называется foo_3. Предыдущая версия все еще существует, а клиенты могут медленно перейти на новую версию.

Если это изменение не вызывает никаких действий со стороны клиентов, мы называем это частное управление версиями. Обычно это отображается в сочетании с публичной версией как часть имени проекта. Используя предыдущий пример, мы имеем WS foo, с частной версией 5 и public 2. Наш проект для этой службы называется WS_foo_2_5. Теперь мы изменим порядок хранения входящих данных. Это не влияет на клиентов, поэтому мы меняем личную версию. Фактически у нас есть проект WS_foo_2_6. Мы создаем из него код-файл foo_2 и развертываем его с URL-адресом, установленным в http://ourserver:8000/foo_2. Таким образом, мы модифицировали версию, не изменяя ничего от клиентов POV.