Каков наилучший способ для версии веб-службы ASP.NET 2.0?

Question

Я поддерживаю веб-службу SOAP (ASP.NET версии 2.0), и я должен внести некоторые изменения, которые изменят возвращаемые значения определенных методов.

Каков общепринятый способ сделать это без нарушения существующих реализаций.

Мои первоначальные мысли состоят в следующем: все возможно.

a) Предоставьте методы новой версии в рамках существующего веб-сервиса, например. getPerson_v1.4
b) Предоставьте полную копию файла .asmx с новым номером версии, например. Http: /www.example.com/AdminWS_V1_4.asmx. Это не идея, которую мне нравится, поскольку у службы более 50 методов и копирование этого кода для изменений в методы 2/3 кажется слишком большим дублированным кодом.
c) Переопределите конструктор веб-сервиса, чтобы разрешить передачу номера версии. Это, похоже, не работает, и по размышлению я не уверен, как это будет представлено в WSDL.

Есть ли общепринятый способ сделать это, или люди имеют советы, основанные на их опыте в этой области.

Answer 1

В общем случае для управления версиями веб-службы больше, чем имена имен версий и имена файлов .asmx. В идеале, интерфейс к веб-сервису (его WSDL) должен быть постоянным контрактом и никогда не должен меняться. Одним из последствий было бы то, что клиентам, которым не нужна измененная функциональность, никогда не нужно будет меняться, и поэтому их никогда не нужно будет проверять.

Вместо того чтобы нарушать существующий договор, вы должны создать новый контракт, который содержит измененные операции. Этот контракт может «наследовать» от существующего контракта, т. Е. Вы можете «добавить методы до конца». Обратите внимание, однако, что вы также должны поместить новый контракт в новое пространство имен XML - пространство имен в основном идентифицирует WSDL и кепинг пространства имен, но изменение WSDL будет ложью.

Затем вы должны реализовать этот новый контракт в новой конечной точке (файл .asmx). Независимо от того, находится ли это в другом каталоге или даже на другом веб-сайте, это не имеет большого значения. Важно то, что клиенты, которым нужна новая функциональность, могут ссылаться на новый WSDL на новый URL-адрес и вызывать новую услугу по новому URL-адресу и быть счастливыми.

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

Answer 2

Мы используем в версии каталогов, например:

http://www.example.com/soap/v1/ http://www.example.com/soap/v2/ http://www.example.com/soap/v3/

т.д.

Answer 3

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

Answer 4

Я только что подумал о другом возможном решении, которое кажется совершенно чистым.

Я могу проверить номер версии, включенную в заголовок SOAP, и принять номер существующей версии, если это не предусмотрено.

Затем я могу сделать код по-разному для разных версий без изменения сигнатур метода. Это возможно, так как возвращаемые значения из Web-сервисов являются объектами XML, поэтому подпись метода остается неизменной, но содержимое XML изменяется в зависимости от версии.

Answer 5

У меня такая же проблема с версиями, что и в веб-сервисах, которые я разрабатываю. Мы заставляем наших пользователей передавать номер версии схемы в заголовке. Они сообщают нам, какую версию схемы XML они хотят вернуть. Таким образом, мы всегда поддерживаем обратную совместимость, а код не дублируется.

На моей работе мы не можем сообщить клиенту, что им нужно переключить URL-адрес на веб-сервис, когда мы его обновляем. В крупных корпорациях изменения размером всего в URL могут занять месяцы тестирования. Я чувствую, что вы не должны разорвать связь с вашими клиентами. Что мы делаем, добавьте новые функции в последнюю версию. Когда клиент запрашивает новые функции, если они этого хотят, они вынуждены обновляться до последней схемы.