Существуют различные способы управления версиями сервисных контрактов на основе политик, приоритетов и требований. Эта вторая статья из серии из двух частей из книги «Разработка контрактов веб-сервисов и управление версиями для SOA» представляет три общие стратегии управления версиями: строгую, гибкую и свободную. Плюсы и минусы каждого подхода обсуждаются и далее ранжируются в отношении строгости, влияния на управление и сложности. Роль идентификаторов версий также рассматривается на ряде примеров. Прочитайте Часть I Здесь.
Следующая статья Томаса Эрла , Дэвида Орчарда и Джеймса Паслиявляется отрывком из новой книги «Разработка и создание версий контрактов веб-сервисов для SOA» [REF-1] Copyright 2008 Prentice Hall / Pearson PTR и SOA Systems Inc. Холл. Статья впервые появилась в журнале SOA ( www.soamag.com ).
Идентификаторы версий
Одним из наиболее фундаментальных шаблонов проектирования, связанных с проектированием контрактов веб-сервисов, является шаблон Идентификации версий. По сути, он выступает за то, чтобы номера версий были четко выражены не только на уровне контракта, но и вплоть до версий схем, лежащих в основе определений сообщений.
Первым шагом к созданию эффективной стратегии управления версиями является выбор общих средств, с помощью которых сами версии идентифицируются и представляются в контрактах на веб-службы.
Версии почти всегда сообщаются с номерами версий. Наиболее распространенным форматом является десятичный, за которым следует точка, а затем еще один десятичный, как показано здесь:
version="2.0"
Иногда вы увидите дополнительные пары период + десятичная дробь, которые приведут к более подробным номерам версий, например:
version="2.0.1.1"
Типичное значение, связанное с этими числами, является мерой или значимостью изменения. Увеличение первого десятичного знака обычно указывает на значительное изменение версии (или обновление) программного обеспечения, тогда как десятичные дроби после первого периода обычно представляют различные уровни незначительных изменений версии.
С точки зрения совместимости мы можем связать дополнительное значение с этими числами. В частности, в отрасли появилось следующее соглашение:
- Предполагается, что минорная версия будет обратно совместима с другими минорными версиями, связанными с основной версией. Например, версия 5.2 программы должна быть полностью обратно совместима с версиями 5.0 и 5.1.
- Основная версия, как правило, должна нарушать обратную совместимость с программами, относящимися к другим основным версиям. Это означает, что версия 5.0 программы не должна быть обратно совместимой с версией 4.0.
Это соглашение об указании совместимости через старшие и младшие номера версий называется гарантией совместимости. Другой подход, известный как «объем работы», использует номера версий, чтобы сообщить об усилиях, которые были внесены в изменение. Незначительное увеличение версии указывает на скромные усилия, а значительное увеличение версии, как ожидается, представляет собой большую работу.
Эти два соглашения могут быть объединены и часто так и есть. Результатом часто является то, что номера версий продолжают сообщать совместимость, как объяснено ранее, но они иногда увеличиваются на несколько цифр, в зависимости от количества усилий, приложенных к каждой версии.
Существуют различные варианты синтаксиса для выражения номеров версий. Например, вы могли заметить, что оператор объявления, начинающий XML-документ, может содержать число, выражающее версию используемой спецификации XML:
<?xml verison="1.0"?>
Тот же атрибут версии можно использовать с корневым элементом xsd: schema следующим образом:
<xsd:schema version="2.0" ...>
Кроме того, вы можете создать собственный вариант этого атрибута, назначив его любому элементу, который вы определили (в этом случае вы не обязаны называть атрибут «версия»).
<LineItem version="2.0">
Альтернативный пользовательский подход заключается во внедрении номера версии в пространство имен, как показано здесь:
<LineItem xmlns="http://actioncon.com/schema/po/v2">
Обратите внимание, что стало общепринятым условием использования значений даты в пространствах имен при управлении версиями XML-схем, а именно:
<LineItem xmlns="http://actioncon.com/schema/po/2010/09">
В этом случае именно дата изменения действует как идентификатор версии. Чтобы привести выражения версий определения XML-схемы в соответствие с версиями определений WSDL, мы будем использовать номера версий вместо значений даты в примерах в следующих главах. Однако при работе в среде, где определения XML-схемы принадлежат отдельно как часть независимой архитектуры данных, нередко идентификаторы контроля версий схемы отличаются от тех, которые используются определениями WSDL.
Независимо от того, какой вариант вы выберете, важно учитывать паттерн канонического управления версиями, который диктует, что выражение информации о версии должно быть стандартизировано во всех контрактах на обслуживание в пределах границ сервисного реестра. В больших средах для этого часто требуется центральный орган, который может гарантировать линейность, согласованность и качество описания информации о версии. Эти типы соглашений переносятся на то, как выражается информация о прекращении обслуживания (как более подробно рассматривается в главе 23).
Примечание. Конечно, вам также может потребоваться работать со сторонними схемами и определениями WSDL, которые, возможно, уже реализовали свои собственные соглашения о версиях. В этом случае степень применения шаблона канонического управления версиями будет ограничена.
Стратегии управления версиями
Не существует единого подхода к управлению версиями, который подходит всем. Поскольку управление версиями представляет собой связанную с управлением фазу в общем жизненном цикле службы, это практика, которая подчиняется соглашениям, предпочтениям и требованиям, характерным для любого предприятия.
Несмотря на то, что не существует методики управления версиями для контента WSDL, XML-схемы и WS-Policy, который включает в себя контракты на веб-сервисы, появился ряд общих и рекомендуемых подходов к управлению версиями, каждый из которых имеет свои преимущества и недостатки.
В этой главе мы собираемся выделить следующие три известные стратегии:
Строгий— Любые совместимые или несовместимые изменения приводят к новой версии контракта на обслуживание. Этот подход не поддерживает обратную или прямую совместимость.
Гибкость — любое несовместимое изменение приводит к новой версии контракта на обслуживание, и контракт предназначен для обеспечения обратной совместимости, но не для прямой совместимости.
Loose — любое несовместимое изменение приводит к появлению новой версии контракта на обслуживание, и контракт предназначен для обеспечения обратной совместимости и прямой совместимости.
Эти стратегии объясняются индивидуально в следующих разделах и упоминаются в оставшихся главах.
Стратегия № 1: Строгая Стратегия (Новое Изменение, Новый Контракт)
Простейший подход к управлению версиями контракта веб-службы состоит в том, чтобы требовать выпуска новой версии контракта всякий раз, когда в какую-либо часть контракта вносятся какие-либо изменения.
Обычно это реализуется путем изменения значения целевого пространства имен определения WSDL (и, возможно, определения схемы XML) каждый раз, когда в содержимое WSDL, XML-схемы или WS-Policy, относящееся к контракту, вносится совместимое или несовместимое изменение. Пространства имен используются для идентификации версии вместо атрибута версии, поскольку изменение значения пространства имен автоматически вызывает изменение во всех пользовательских программах, которым требуется доступ к новой версии схемы, которая определяет типы сообщений.
Этот «сверхсильный» подход не очень практичен, но он наиболее безопасен и иногда оправдан, когда существуют юридические последствия для изменений контракта веб-службы, например, когда контракты публикуются для определенных обменов данными между организациями. Поскольку как совместимые, так и несовместимые изменения приведут к новой версии контракта, этот подход не поддерживает обратную или прямую совместимость.
Плюсы и минусы
Преимущество этой стратегии заключается в том, что вы имеете полный контроль над развитием контракта на обслуживание, и поскольку обратная и прямая совместимость преднамеренно игнорируются, вам не нужно беспокоиться о влиянии какого-либо конкретного изменения (поскольку все изменения эффективно нарушают договор).
С другой стороны, налагая новое пространство имен на контракт с каждым изменением, вы гарантируете, что все существующие потребители услуг больше не будут совместимы с любой новой версией контракта. Потребители смогут продолжать связь с веб-службой только в том случае, если старый контракт остается доступным вместе с новой версией или до тех пор, пока сами потребители не обновятся в соответствии с новым договором.
Следовательно, такой подход увеличит бремя управления отдельными услугами и потребует тщательных переходных стратегий. Наличие двух или более версий одной и той же услуги одновременно может стать общим требованием, для которого необходимо подготовить вспомогательную инфраструктуру инвентаризации услуг.
Стратегия № 2: гибкая стратегия (обратная совместимость)
Общий подход, используемый для балансирования практических соображений с попыткой свести к минимуму влияние изменений в контрактах на веб-сервисы, заключается в том, чтобы позволить совместимым изменениям происходить без форсирования новой версии контракта, при этом вообще не пытаясь поддерживать прямую совместимость.
Это означает, что любое обратно совместимое изменение считается безопасным в том смысле, что в конечном итоге оно продлевает или дополняет установленный договор, не затрагивая ни одного из существующих потребителей услуги. Типичным примером этого является добавление новой операции в определение WSDL или добавление необязательного объявления элемента в определение схемы сообщения.
Как и в случае стратегии Strict, любое изменение, нарушающее существующий контракт, приводит к новой версии контракта, обычно реализуемой путем изменения значения целевого пространства имен в определении WSDL и, возможно, также в определении схемы XML.
Плюсы и минусы
Основным преимуществом этого подхода является то, что он может использоваться для учета различных изменений, при этом последовательно сохраняя обратную совместимость контракта. Однако, когда совместимые изменения сделаны, эти изменения становятся постоянными и не могут быть отменены без внесения несовместимых изменений. Следовательно, необходим процесс управления, в ходе которого оценивается каждое предлагаемое изменение, чтобы контракты не были чрезмерно раздутыми или запутанными. Это особенно важно для агностических служб, которые активно используются повторно.
Стратегия № 3: свободная стратегия (обратная и прямая совместимость)
Как и в предыдущих двух подходах, эта стратегия требует, чтобы несовместимые изменения приводили к новой версии контракта на обслуживание. Разница здесь в том, как изначально оформляются контракты на обслуживание.
Вместо того, чтобы соответствовать известным требованиям к обмену данными, используются специальные функции из языков WSDL, XML-схемы и WS-Policy, чтобы сделать части контракта внутренне расширяемыми, чтобы они могли поддерживать широкий диапазон будущих, неизвестных требований к обмену данными.
Например:
- Значение атрибута anyType, предоставляемое языком WSDL 2.0, позволяет сообщению состоять из любого допустимого XML-документа.
- Подстановочные знаки схемы XML можно использовать для передачи диапазона неизвестных данных в определениях сообщений.
- Могут быть определены игнорируемые утверждения политики для передачи характеристик услуг, которые могут быть дополнительно признаны будущими потребителями.
Эти и другие функции, связанные с прямой совместимостью, обсуждаются в следующих главах.
Плюсы и минусы
Тот факт, что подстановочные знаки позволяют передавать неопределенный контент через контракты веб-служб, дает постоянную возможность для дальнейшего расширения диапазона приемлемых элементов сообщения и содержимого данных. С другой стороны, использование подстановочных знаков, естественно, приведет к расплывчатым и чрезмерно грубым контрактам на обслуживание, которые возлагают бремя проверки на основную логику обслуживания.
Примечание . На все три стратегии будут ссылаться в следующих главах, поскольку мы исследуем, как можно осуществлять управление версиями с помощью WSDL, XML-схемы и WS-Policy.
Заключение.
Здесь представлена таблица, в которой в общих чертах суммируется сравнение трех стратегий на основе трех основных характеристик.
Таблица 1 — Общее сравнение трех стратегий управления версиями.
Три характеристики, используемые в этой таблице для формирования основы сравнения:
- Строгость — жесткость вариантов управления контрактом. Строгий подход, безусловно, является наиболее жестким в правилах управления версиями, в то время как стратегия Loose предоставляет широчайший диапазон вариантов управления версиями благодаря своей зависимости от подстановочных знаков.
- Влияние на управление — Количество бремени управления, налагаемого стратегией. И Строгий и Свободный подходы увеличивают влияние управления, но по разным причинам. Стратегия Strict требует выпуска новых версий контрактов, которые влияют на окружающих потребителей и инфраструктуру, в то время как подход Loose вводит концепцию неизвестных наборов сообщений, которые необходимо отдельно адаптировать с помощью пользовательского программирования.
- Сложность — общая сложность процесса управления версиями. Из-за использования подстановочных знаков и неизвестных данных сообщений стратегия Loose обладает наивысшим потенциалом сложности, в то время как простые правила, лежащие в основе строгого подхода, делают его наиболее простым вариантом.
На протяжении этого сравнения Гибкая стратегия обеспечивает подход, который представляет неизменно средний уровень строгости, усилий по управлению и общей сложности.
Каждая стратегия также определяет, как совместимые изменения, несовместимые изменения и идентификаторы версий используются и применяются в поддержку правил и соглашений стратегии. В главах 21, 22 и 23 рассматривается применение этих стратегий по отдельности к определениям WSDL, определениям схемы XML и определениям WS-Policy.
Рекомендации
[REF-1] «Разработка контрактов веб-сервисов и управление версиями для SOA» Томаса Эрла, Аниша Кармаркара, Присциллы Уолмсли, Хьюго Хааса, Умит Ялкинальп, Каньянга Кевина Лю, Дэвида Орчарда, Андре Тоста, Джеймса Пасли для «Prentice Hall Service- Серия ориентированных вычислений от Томаса Эрла «, Copyright 2008 Prentice Hall / Pearson PTR и SOA Systems Inc., http://www.soabooks.com/wsc/
Эта статья была первоначально опубликована в журнале The SOA Magazine ( www.soamag.com ), официально связанном с серией сервис-ориентированных вычислений Prentice Hall от Томаса Эрла ( www.soabooks.com ). Copyright © SOA Systems Inc. ( www.soasystems.com )