Изменения реализации веб-сервиса

Question

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

В какой степени потребители должны быть уведомлены об изменениях реализации?Одно дело уведомлять потребителей об обновлениях вашей собственной реализации веб-сервиса.Насколько реально отслеживать изменения реализации для всех последующих зависимостей?Должны ли владельцы услуг создавать новую версию, когда они знают, что изменение может повлиять на потребителей?И пытаться быть хорошим гражданином и уведомлять потребителей обо всех других изменениях?

Множество вопросов, и я сомневаюсь, что один ответ подходит всем.Это может просто зависеть от ситуации.Может быть, это то, для чего SLA.

Answer 1

Я нахожусь в среде, где SLA не существует для внутренних клиентов, поэтому в отсутствие SLA ниже приведены некоторые руководящие принципы здравого смысла

1. Попытка ограничить количество модификаций услуг
2. Сообщите о реализации сервисов, чтобы потребители могли планировать циклы тестирования
3. Предоставить потребителям список прямых нисходящих зависимостей и местоположения, чтобы найти их графики и заметки о выпуске
4. Рассмотрим новую версию, если изменение реализации семантически повлияет на потребителя

Answer 2

Многое зависит от ваших конкретных обстоятельств.Говоря в целом, вот несколько главных соображений.

Сервисный контракт и схема - это все, что сервис и клиент совместно используют.Изменение реализации сервиса, которое не меняет контракт или схему (например, исправление ошибки в логике реализации), не должно требовать уведомления клиентов и не должно рассматриваться как новая версия.

OTOH, если у вас естьплохо составленный, чрезмерно свободный контракт, такой как передача всех данных в виде одной большой строки, когда клиент должен был провести расширенную интерпретацию, чтобы использовать сервис, и теперь вы ищете способ использовать этот чрезмерно свободный контракт таким образомэто может привести к поломке клиента, вы обязаны всем сторонам изменить договор (и улучшить его!) и опубликовать его в качестве новой версии службы.

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

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

Книга Томаса Эрла Проектирование и управление версиями Web-сервисов для SOA - хороший ресурс по теме и подробности.несколько распространенных сценариев.

Answer 3

Хорошие вопросы, и я думаю, что вы уже ответили на них.Да, эти детали были бы в SLA, и я думаю, что если контракт / WSDL такой же, то почему сервис должен уведомлять своих потребителей?Если, конечно, изменения в обслуживании не влияют на время отклика и производительность.Возможно, сервис будет уведомлять потребителей, когда будет введен другой контракт (в дополнение к оригиналу).Потребители узнают о любых новых возможностях и могут настроить своих клиентов соответствующим образом.