Проектирование для управления SOA

Ниже приводится отрывок главы из недавно опубликованной книги «Шаблоны проектирования SOA»
(Erl et al., ISBN: 0136135161, Prentice Hall, 2009)
. Шаблоны управления в этой главе фокусируются только на вопросах управления, связанных с дизайном, которые относятся к архитектуре сервиса. Предстоящая книга «Управление SOA», входящая в эту серию книг, предоставит сборник более широких технических и организационных рекомендаций и шаблонов.
  

 

 

Шаблоны управления сервисами

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

Совместимые изменения (465) и Идентификация версии (472) направлены на создание версий контрактов на обслуживание. Аналогичным образом, Уведомление о прекращении (478) касается прекращения услуг или контрактов на обслуживание.

Самым фундаментальным шаблоном в этой главе является Service Refactoring (484), который использует слабо (и в идеале отделенный) контракт, чтобы позволить базовой логике и реализации быть обновленными и улучшенными.

Трио «Декомпозиция услуг» (489), «Разложенная возможность» (504) и «Возможность прокси» (497) устанавливают методы, позволяющие физически разделить грубые службы на несколько мелкозернистых служб, что может помочь еще больше улучшить производительность композиции. Распределенная возможность (510) также предоставляет специализированное проектное решение, связанное с рефакторингом, которое помогает повысить масштабируемость обслуживания посредством отсрочки внутренней распределенной обработки.

Совместимое изменение

Дэвид Орчард, Крис Райли

Как можно изменить договор на обслуживание, не влияя на потребителей?

Таблица 16.1
Сводная информация профиля для шаблона «Совместимые изменения».

проблема

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

Рисунок 16.1
. Название сервисной возможности изменяется после того, как версия 1 сервисного контракта уже используется. В результате версия 2 контракта несовместима с потребителем А.

Решение

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

Рисунок 16.2
. Существующая возможность не переименована. Вместо этого добавляется новая возможность с новым именем наряду с первоначальной возможностью, тем самым сохраняя совместимость как с потребителями A, так и с B.

заявка

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

Вот набор общих изменений для контрактов веб-служб, а также описания того, как (или в какой степени) эти изменения могут применяться обратно совместимым образом:

• Добавление новой операции к определению WSDL . Операцию можно просто добавить к существующему определению, тем самым действуя как расширение договора, не влияя на какое-либо установленное содержание договора.

• Переименование существующей операции. Как объяснено на предыдущих диаграммах, операцию можно переименовать, добавив новую операцию с новым именем вместе с существующей операцией со старым именем. Этот подход может быть дополнительно дополнен уведомлением о прекращении (478), если существует необходимость в конечном итоге отказаться от первоначальной операции, в то же время позволяя потребителям, зависящим от этой операции, обновлять льготный период в поддержку переименованной операции.

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

• Изменение MEP существующей операции. Чтобы изменить шаблон обмена сообщениями операции, необходимо изменить определения входных и выходных сообщений (и, возможно, определение ошибки), что обычно является несовместимым изменением. Для продолжения этого изменения при сохранении обратной совместимости требуется, чтобы новая операция с измененным MEP была добавлена ​​к определению WSDL вместе с исходной операцией. Как и при переименовании операции таким способом, Уведомление о завершении (478) может использоваться для содействия возможному переходу.

• Добавление сообщения об ошибке в существующую операцию — добавление сообщения об ошибке (если рассматривать его отдельно от изменения в MEP) часто может выглядеть как совместимое изменение, поскольку вариант выдачи сообщения об ошибке не влияет на основные функциональные возможности операции. , Однако, поскольку это дополнение увеличивает поведение службы, его следует рассматривать как изменение, которое может быть совместимо только при добавлении сообщения об ошибке как части новой операции.

• Добавление нового типа порта — поскольку определения WSDL допускают существование нескольких определений типа порта, контракт на обслуживание можно расширить, добавив новый тип порта наряду с существующим. Хотя это представляет собой форму совместимых изменений, может быть более желательно просто выпустить новую версию всего контракта веб-службы.

• Добавление нового элемента или атрибута схемы сообщения. Новые элементы или атрибуты могут быть добавлены в существующую схему сообщения как совместимое изменение, если они являются необязательными. Таким образом, их присутствие не повлияет на постоянных потребителей услуг, которые были разработаны до их существования.

• Удаление существующего элемента или атрибута схемы сообщения — независимо от того, являются ли они необязательными или обязательными, если уже установленные элементы или атрибуты схемы сообщения необходимо удалить из контракта на обслуживание, это приведет к несовместимому изменению. Следовательно, этот шаблон не может быть применен в этом случае.

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

• Добавление новой политики. Один или несколько операторов WS-Policy можно добавить с помощью Compatible Change, просто добавив альтернативы политики к существующей точке присоединения политики.

• Добавление утверждений политики. Утверждение политики может быть добавлено в соответствии с Совместимым изменением (465) к существующей политике, если оно является необязательным или добавлено как часть отдельной политики в качестве альтернативы политике.

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

---

Примечание. Этот список изменений соответствует серии разделов в главах 21, 22 и 23 в книге Проектирование контрактов веб-служб и управление версиями для SOA, в которой рассматриваются совместимые и несовместимые сценарии изменений с примерами кода.

---

Воздействие

Каждый раз, когда уже опубликованный контракт на обслуживание изменяется, требуется управление версиями и управление, чтобы гарантировать, что изменение будет представлено как новая версия контракта и будет должным образом выражено и доведено до сведения существующих и новых потребителей. Как объясняется в следующем разделе « Отношения », это приводит к использованию канонического управления версиями (286) и идентификации версий (472).

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

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

Отношения

Чтобы последовательно применять этот шаблон для нескольких служб, необходимо наличие официальной системы управления версиями, которая идеально стандартизирована в соответствии с каноническим управлением версиями (286). Кроме того, этот шаблон зависит от Идентификации Версии (472), чтобы гарантировать, что изменения выражены должным образом, и может также потребовать Уведомления о Прекращении (478) для перевода контента контракта и потребителей со старых версий на новые.

Рис. 16.3.
Совместимые изменения относятся к нескольким другим шаблонам управления услугами, но также могут зависеть от некоторых шаблонов разработки контрактов.

---

Пример тематического исследования

Как описано в примере тематического исследования для денормализации контракта (414), контракт на обслуживание сотрудника был недавно продлен архитекторами FRC для включения новой операции UpdateLog.

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

Архитекторы умоляют менеджера QA, что эти дополнительные циклы тестирования не нужны. Они объясняют, что содержимое контракта было добавлено только путем добавления операции UpdateLog, и ни один из ранее существовавших кодов контракта не был затронут, как показано в выделенных частях этого примера:

<definitions name=”Officer” 
  targetNamespace=”http://frc/officer/wsdl/” 
  xmlns=”http://schemas.xmlsoap.org/wsdl/” 
  xmlns:off=”http://frc/officer/schema/” 
  xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” 
  xmlns:tns=”http://frc/officer/wsdl/” 
  xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <types>
    <xsd:schema targetNamespace=”http://frc/officer/”>	
      <xsd:import namespace=”http://frc/officer/schema/” 
        schemaLocation=”Officer.xsd”/> 
    </xsd:schema>
  </types>
  <message name=”UpdateOfficer”>
    <part name=”RequestA” element=”off:OfficerDoc”/>
  </message>
  <message name=”UpdateOfficerConfirm”>
    <part name=”ResponseA” element=”off:ReturnCodeA”/>
  </message>
  <message name=”UpdateOfficerLog”>
    <part name=”RequestB” element=”off:OfficerLog”/>
  </message>
  <message name=”UpdateOfficerLogConfirm”>
    <part name=”ResponseB” element=”off:ReturnCodeB”/>
  </message>
  <portType name=”OffInt”>
    <operation name=”Update”>
      <input message=”tns:UpdateOfficer”/>
      <output message=”tns:UpdateOfficerConfirm”/>
    </operation>
    <operation name=”UpdateLog”>
      <input message=”tns:UpdateOfficerLog”/>
      <output message=”tns:UpdateOfficerLogConfirm”/>
    </operation>
  </portType>
  ...
</definitions>

Пример 16.1.
Определение WSDL из примера 14.1 пересмотрено, чтобы показать, как изменение, внесенное во время применения денормализации контракта (414), было обратно совместимым.

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

---

Идентификация версии

Дэвид Орчард, Крис Райли

Как потребители могут узнать информацию о версии контракта на обслуживание?

Таблица 16.2
Сводная информация о профиле для шаблона идентификации версии.

проблема

Независимо от того, подвержен ли контракт совместимым или несовместимым изменениям, любое изменение его опубликованного контента обычно требует новой версии контракта. Без возможности связать версии контракта с изменениями совместимость между службой и ее нынешними и новыми потребителями постоянно находится под угрозой, и услуга также становится менее доступной для разработчиков для потребителей ( рисунок 16.4 ).

Рисунок 16.4
Поскольку контракт на обслуживание требуется изменить, потребитель сервиса остается в неведении относительно того, является ли он все еще совместимым.

Кроме того, сама служба также становится более обременительной для управления и развития.

Решение

Контракт на обслуживание может быть разработан для выражения идентификаторов версий, которые позволяют потребителю уверенно определять, совместим ли он с сервисом. Использование идентификаторов версий дополнительно поддерживает Concurrent Contracts (421) для целей управления версиями, что позволяет потребителю выбрать правильный контракт на основе его выраженной версии, как показано на рисунке 16.5 .

Рис. 16.5.
Поскольку контракты на обслуживание выражают информацию о версиях, Потребитель А может приступить к вызову версии 3 контракта на обслуживание, поскольку он был разработан для совместимости с этой конкретной версией.

заявка

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

Что на самом деле означают номера версий, зависит от соглашений, установленных всеобъемлющей стратегией управления версиями. Здесь описаны два общих подхода:

• Объем работы — Основные и вспомогательные номера версий используются для указания количества усилий, затраченных на каждое изменение. Увеличение основного номера версии представляет собой значительный объем работы, тогда как увеличение младших номеров версии представляет собой незначительные обновления.

• Гарантия совместимости — старший и младший номера версий используются для выражения совместимости. Наиболее распространенная система основана на правиле, согласно которому увеличение номера основной версии приводит к тому, что контракт не является обратно совместимым, тогда как увеличение числа младших версий обратно совместимо. В результате незначительные приращения версий не должны влиять на существующих потребителей.

Обратите внимание, что эти две системы идентификации могут быть объединены так, чтобы увеличение номера версии продолжало указывать на совместимые или несовместимые изменения, а также представлять объем работы, который был внесен в изменения.

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

---

Примечание. В то время как номера версий часто включаются в целевые пространства имен для определений WSDL, значения дат обычно добавляются в целевые пространства имен для определений схемы XML. См. Главы 20, 21 и 22 в книге Проектирование контрактов и управление версиями для SOA для примеров кода и более подробной информации.

---

Воздействие

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

Когда сервисы подвергаются воздействию новых или внешних потребителей, применяются те же самые требования, но необходимое соблюдение стандартов может быть более трудным для достижения.

Отношения

Этот шаблон обычно применяется вместе (или в результате) применения канонического управления версиями (286) и, кроме того, является неотъемлемой частью проведения совместимых изменений (465).

Рисунок 16.6
Идентификация версии относится в основном к другим шаблонам управления версиями контракта.

---

Примечание. Идентификация версии сопоставима с индикатором формата (Hohpe, Woolf), когда применяется для выражения номера версии как части сообщения. Индикатор формата отличается тем, что он ориентирован на сообщения, а также позволяет выражать другую метаинформацию, такую ​​как внешние ключи и форматы документов.

---

---

Пример тематического исследования

Как объяснено в примере для примера «Совместимые изменения» (465), группа обеспечения качества проводит дополнительное тестирование службы «Сотрудник» с расширенным контрактом на обслуживание. После проведения этих испытаний они очищают новую услугу для выпуска в производство, при условии соблюдения одного условия: в контракте на обслуживание должен быть указан номер версии, чтобы указать, что она была изменена.

Этот номер версии соответствует существующим соглашениям о версиях, согласно которым обратно-совместимое изменение увеличивает младший номер версии (цифра после десятичной точки). Архитекторы FRC согласны с тем, что это хорошая идея, и быстро добавляют удобочитаемый комментарий к определению WSDL сотрудника, используя следующий элемент документации:

<definitions name=”Officer” 
  targetNamespace=”http://frc/officer/wsdl/” 
  xmlns=”http://schemas.xmlsoap.org/wsdl/” 
  xmlns:off=”http://frc/officer/schema/” 
  xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” 
  xmlns:tns=”http://frc/officer/wsdl/” 
  xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <documentation>Version 1.1</documentation>
  ...
</definitions>

Пример 16.2.
Определение WSDL из примера 16.1 снабжено номером версии.

Через несколько месяцев после развертывания версии 1.1 службы Officer были запущены два новых проекта, каждый из которых относится к системе управления персоналом, которая в настоящее время действует. Один из корпоративных архитекторов FRC связан с обеими проектными командами для обеспечения соответствия стандартам проектирования. Изучив каждую спецификацию дизайна, она замечает некоторую общность. Первое решение требует регистрации событий, а другое решение требует регистрации ошибок. Вскоре она понимает, что FRC необходимо создать отдельную утилиту Logging Service.

После предложения ее рекомендации, сервис Logging встроен в поддержку обоих решений. Несколько недель спустя, во время анализа концепции инвентаризации услуг, аналитик отмечает, что операция UpdateLog, которая была добавлена ​​в контракт на обслуживание Officer, на самом деле должна находиться в новой службе ведения журнала.

Команда разработчиков FRC соглашается внести это изменение, хотя это и не считается непосредственным приоритетом. Спустя несколько недель сервис Officer вновь посещается, и логика операции UpdateLog удаляется. В результате сама операция UpdateLog удаляется из договора.

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

<definitions name=”Officer” 
  targetNamespace=”http://frc/officer/wsdl/v2” 
  xmlns=”http://schemas.xmlsoap.org/wsdl/” 
  xmlns:off=”http://frc/officer/schema/” 
  xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” 
  xmlns:tns=”http://frc/officer/wsdl/v2” 
  xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <documentation>Version 2.0</documentation>
  <types>
    <xsd:schema targetNamespace=”http://frc/officer/”>	
      <xsd:import namespace=”http://frc/officer/schema/” 
        schemaLocation=”Officer.xsd”/> 
    </xsd:schema>
  </types>
  <message name=”UpdateOfficer”>
    <part name=”RequestA” element=”off:OfficerDoc”/>
  </message>
  <message name=”UpdateOfficerConfirm”>
    <part name=”ResponseA” element=”off:ReturnCodeA”/>
  </message>
  <portType name=”OffInt”>
    <operation name=”Update”>
      <input message=”tns:UpdateOfficer”/>
      <output message=”tns:UpdateOfficerConfirm”/>
    </operation>
  </portType>
  ...
</definitions>

Пример 16.3
Операция UpdateLog удаляется из пересмотренного определения Officer WSDL, что приводит к несовместимому изменению, которое требует нового целевого значения пространства имен.

---

Уведомление о прекращении

Дэвид Орчард, Крис Райли

Как можно сообщить о запланированном истечении контракта на обслуживание программам для потребителей?

Таблица 16.3
Сводная информация профиля для шаблона уведомления о завершении.

проблема

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

Примеры включают в себя:

• контракт на обслуживание подвержен несовместимым изменениям

• совместимое изменение применяется к контракту на обслуживание, но строгие политики управления версиями требуют выдачи совершенно новой версии контракта на обслуживание

• первоначальная функциональная сфера услуг больше не применима в связи с тем, как изменился бизнес

• услуга разбита на более детализированные услуги или объединена вместе с другой услугой

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

Неспособность распознать запланированное отключение неизбежно приведет к сценариям сбоев во время выполнения, в которых незнакомые пользовательские программы, которые пытаются вызвать службу, отклоняются ( рисунок 16.7 ).

Рисунок 16.7
. Потребительская программа (справа) вызывает сервис через свой контракт, как обычно сегодня, но когда контракт прекращается на следующий день, попытка вызова не удалась.

Решение

Контракты на обслуживание снабжены деталями расторжения, что позволяет потребителям заблаговременно узнавать о выходе из контракта ( Рисунок 16.8 ).

Рисунок 16.8
Договор на обслуживание включает в себя стандартизированное заявление, которое сообщает, когда оно запланировано для прекращения. В результате потребитель не пытается вызвать его после расторжения договора.

заявка

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

Стоит также отметить, что в дополнение к выражению расторжения контракта на обслуживание существуют и другие цели, для которых может применяться Уведомление о прекращении, например:

• Обозначение отмены конкретной возможности или операции. Это особенно актуально при выборе одного из методов перехода, описанных в «Совместимое изменение» (465), где сохраняется исходная операция и добавляется аналогичная, но измененная операция.

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

• Указание на прекращение использования схемы сообщений. Хотя утверждения политики могут не подходить для этой цели, в схемы можно добавлять регулярные аннотации, чтобы объяснить, когда версия схемы будет прекращена и / или заменена.

Также обратите внимание, что стандарты управления могут быть внедрены как часть всеобъемлющей стратегии Canonical Versioning (286), чтобы выразить информацию уведомления о прекращении через стандартизированные аннотации или не игнорируемые утверждения политики. В последнем случае для этого может потребоваться, чтобы все контракты веб-служб содержали утверждения о прекращении независимо от того, подлежат ли они прекращению. Для тех контрактов, которые не расторгнуты, предварительно заданное значение, указывающее это, помещается в утверждение вместо даты (или утверждение остается пустым).

Воздействие

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

Отношения

Как только что упомянуто, то, как этот шаблон применяется, часто регулируется каноническим версионированием (286). Совместимые изменения (465) и Proxy Capability (497) могут привести к необходимости уведомления о завершении.

Рис. 16.9.
Уведомление о прекращении относится в основном к другим шаблонам управления версиями, но также может поддерживать Proxy Capability (497).

---

Примечание. Уведомление о прекращении действия по своей сути аналогично окончанию срока действия сообщения (Hohpe, Woolf) — шаблону, в котором рекомендуется добавлять в сообщение метку времени, чтобы указать, когда само сообщение больше не считается действительным.

---

---

Пример тематического исследования

В примере для Идентификации версии (472) команда FRC удалила операцию UpdateLog из определения WSDL Officer, что привело к несовместимому изменению. После встречи с некоторыми хранителями потребительских программ, затронутых этим несовместимым изменением, архитекторы FRC начинают понимать, что изменение приведет к значительным усилиям со стороны владельцев потребителей и что может пройти несколько месяцев, прежде чем все потребительские программы обновлены для работы с новой утилитой Logging Service. Кроме того, некоторые из лиц, ответственных за владение потребителями, были недоступны и должны будут быть проинформированы о предстоящих изменениях на более позднем этапе.

В результате этих обстоятельств команда FRC решает отложить изменение, позволяя службе Officer поддерживать свою операцию UpdateLog в течение следующих шести месяцев, пока также доступна служба ведения журнала. Они работают с группой обеспечения качества над планом, чтобы учесть этот переход, следующим образом:

1. Установите новый стандарт разработки, который запрещает доступу любых новых пользовательских программ к операции UpdateLog службы Officer.

2. Сообщите всем руководителям группы по электронной почте о дате, когда операция UpdateLog будет удалена.

3. Включите эту дату прекращения в определение Officer WSDL с помощью невнимательного утверждения политики.

Шаг 3 реализован следующим образом:

<definitions name=”Officer” ... >
  ...
  <binding name=”bdPO” type=”tns:OffInt”>
    <operation name=”Update”>   
      <soapbind:operation    
        soapAction=”http://frc/update/request”
        soapActionRequired=”true” required=”true”/>
      <input>
        <soapbind:body use=”literal”/>
      </input>
      <output> 
        <soapbind:body use=”literal”/>  
      </output>
    </operation>
    <operation name=”UpdateLog”>   
      <wsp:Policy>
        <pol:termination wsp:Ignorable=”true”>
          Mar-01-2009
        </pol:termination>
      </wsp:Policy>
      <soapbind:operation    
        soapAction=”http://frc/updateLog/request”
        soapActionRequired=”true” required=”true”/>
      <input>
        <soapbind:body use=”literal”/>
      </input>
      <output> 
        <soapbind:body use=”literal”/>  
      </output>
    </operation>
      ...
  </binding>
  ...
</definitions>

Пример 16.4
Элемент операции в структуре привязки определения WSDL Officer изменяется, чтобы включить настраиваемое игнорируемое утверждение WS-Policy, которое выражает запланированную дату завершения операции UpdateLog.

---

---

Примечание. Дополнительные примеры уведомлений о прекращении см. В главе 23 «Разработка контрактов веб-служб и управление версиями для SOA».

---

Рефакторинг услуг

Как развить услугу, не влияя на существующих потребителей?

Таблица 16.4
Сводная информация профиля для шаблона рефакторинга сервиса.

проблема

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

Рисунок 16.10.
Потребители существующего сервиса требуют новых требований, для которых сервис изначально не был разработан. Красные символы обозначают различные части этой сервисной архитектуры, которые могут быть независимо от версии.

Решение

Рефакторинг программного обеспечения — это общепринятая практика разработки программного обеспечения, при которой существующие программы могут постепенно улучшаться, не влияя на их поведение. При применении к проектированию услуг этот подход предоставляет больше возможностей для развития служб в организации, не нарушая их существующих потребителей. Как показано на рисунке 16.11 , с применением этого шаблона базовая логика и реализация службы могут регулярно оптимизироваться, улучшаться или даже обновляться при сохранении контракта на обслуживание.

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

заявка

Методы рефакторинга программного обеспечения позволяют усовершенствовать программы с помощью серии небольших обновлений, которые продолжают сохранять свои интерфейсы и общее поведение. Ограничивая объем этих обновлений, риск, связанный с негативным воздействием на потребителей, сводится к минимуму. Акцент методов рефакторинга программного обеспечения делается на совокупный результат этих отдельных шагов рефакторинга.

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

---

Примечание. Доступно несколько книг, посвященных методам рефакторинга и специальным шаблонам. Два хорошо известных названия: «Рефакторинг»: «Улучшение дизайна существующего кода» (Фаулер, Бек, Брант, Опдике, Робертс) и «Рефакторинг в паттерны» (Кериевский), оба — Аддисон-Уэсли. Сайт http://www.refactoring.com предоставляет дополнительные ресурсы, а также каталог проверенных «рефакторингов».

---

Воздействие

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

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

Отношения

Степень применения рефакторинга услуг зависит от того, как изначально был разработан сам сервис. Вот почему существует прямая связь между этим шаблоном и нормализацией услуг (131), централизацией контрактов (409) и отделенным контрактом (401). Абстракция и независимость, полученные в результате успешного применения этих шаблонов, позволяют индивидуально управлять сервисами и развиваться с минимальным влиянием на потребительские программы.

Кроме того, в зависимости от характера требований к рефакторингу может потребоваться декомпозиция услуг (489), параллельные контракты (421) или фасад услуг (333), чтобы учесть, как улучшается услуга.

Рис. 16.12.
Рефакторинг услуг основан на нескольких ключевых шаблонах, связанных с контрактами, чтобы гарантировать, что изменения, связанные с рефакторингом, не нарушат существующих потребителей услуг.

---

Пример тематического исследования

Служба Alleywood Employee была внедрена некоторое время назад. Первоначально он установил стандартизированный контракт на обслуживание, который действовал как конечная точка в модуле HR большой ERP-системы. После выкупа McPherson различные продукты были модернизированы или заменены, чтобы соответствовать всему ИТ-предприятию. В рамках этой инициативы система ERP была переоценена.

Поставщик ERP был выкуплен конкурирующим производителем программного обеспечения, а платформа ERP просто стала частью более широкой линейки продуктов, предлагающих альтернативную ERP. Группа McPherson считала, что первоначальная среда ERP Alleywood вскоре будет удалена ее новым владельцем, чтобы дать их продукту ERP большую долю рынка.

В результате было решено полностью заменить этот продукт. Это, конечно, коснулось многих сервисов, в том числе сервиса Employee. Однако, поскольку его контракт был отделен и был полностью стандартизирован, он никоим образом не зависел от какой-либо части базовой среды ERP.

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

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

---

Декомпозиция услуг

Как можно повысить степень детализации услуги после ее внедрения?

Таблица 16.5
Сводная информация о профиле для шаблона декомпозиции услуг.

проблема

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

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

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

---

Примечание. Другое обстоятельство, при котором может возникнуть это проблемное состояние, — это когда услуги производятся с помощью процесса доставки «посередине», где нисходящий анализ выполняется только частично до разработки сервиса. При таком подходе к доставке нисходящий процесс продолжается одновременно с проектами предоставления услуг. Существует обязательство пересмотреть внедренные проекты сервисов после того, как нисходящий анализ продвинется до точки, где идентифицированы необходимые изменения в оригинальном инвентаре услуг. Более подробную информацию о стратегиях реализации проектов SOA см. В главе 10 «Сервис-ориентированная архитектура: концепции, технологии и дизайн».

---

Решение

Грубый сервис разлагается на набор детальных сервисов, которые в совокупности представляют функциональный контекст исходного сервиса, но устанавливают свои собственные функциональные контексты ( рисунок 16.14 ).

Рис. 16.14
. Исходная грубая служба счетов-фактур разбита на три отдельные службы, одна из которых остается связанной с общей обработкой счетов-фактур, но содержит только подмножество исходных возможностей.

заявка

Выполнение этого шаблона по существу требует, чтобы существующий, крупнозернистый сервис был разбит на части и его логика реорганизована в новые, более тонкие функциональные границы.

Поэтому первым шагом обычно является пересмотр плана инвентаризации услуг и принятие решения о том, как услуга может быть смоделирована на несколько кандидатов в службы. Как часть этого процесса, новые кандидаты в возможности также должны быть определены, особенно если Decomposed Capability (504) не был принят во внимание во время первоначального проектирования сервиса. После того, как моделирование завершено, новые сервисы проходят стандартные этапы жизненного цикла, начиная с разработки контракта (на основе смоделированных кандидатов на услуги) и вплоть до финальных этапов тестирования и обеспечения качества ( рис. 16.15 ).

Рис. 16.15.
Каждый из новых детализированных сервисов предоставляет меньше возможностей и, следовательно, налагает меньшие размеры программ.

Если не будет решено также модернизировать предыдущие потребительские программы, которые формировали зависимости от исходного сервиса, вероятно, потребуется применить Proxy Capability (497), чтобы сохранить исходный контракт на обслуживание для обратной совместимости.

---

Примечание . Концепции, лежащие в основе этого шаблона, также можно применять в обратном порядке, когда две или более детализированные услуги объединяются в одну крупнозернистую услугу. Использование Proxy Capability (497) все равно будет применяться для сохранения первоначальных сервисных контрактов. Это основа шаблона, называемого Service Consolidation, который на момент написания этой статьи был классифицирован как шаблон-кандидат, который доступен для просмотра на SOAPatterns.org.

---

Воздействие

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

Поскольку этот шаблон обычно применяется после созревания архитектуры инвентаризации, необходимо тщательно спланировать его применение вместе с повторным применением Proxy Capability (497).

Превентивное использование Decomposed Capability (504) может ослабить влияние декомпозиции услуг, а также приведет к более четкому разделению функциональных контекстов обслуживания.

Отношения

Декомпозиция сервиса имеет ряд взаимосвязей с другими шаблонами уровня сервиса, в частности рефакторинг сервиса (484). Когда сервис обновляется в результате усилий по рефакторингу, применение Decomposition Service вполне может быть средством, с помощью которого это выполняется.

Как объяснено в описании шаблона для Proxy Capability (497), декомпозиция службы опирается на этот шаблон для реализации фактического разделения с помощью усилий по реконструкции, необходимых для превращения одной или нескольких обычных возможностей в прокси. В результате этот шаблон использует несколько таких же шаблонов, как Proxy Capability (497).

Декомпозиция сервиса чаще всего применяется к агностическим сервисам, поэтому связывает их с абстракцией сущности (175) и абстракцией полезности (168). Однако результат этого шаблона может ввести меру избыточности сервиса из-за необходимости в Proxy Capability (497) нарушать нормализацию сервиса (131) в некоторой степени.

Рис. 16.16.
Декомпозиция сервиса — это связанный с рефакторингом подход к разделению логики сервиса, который связан с многочисленными паттернами, которые формируют логику сервиса и контракты.

---

Пример тематического исследования

Пример практического примера для Service Refactoring (484) объяснил, как служба Employee была реинжинирирована по ряду причин. Одним из результатов этих усилий является то, что сервис стал более масштабируемым и может справляться с повышенными нагрузками. Основная причина, по которой была решена проблема масштабируемости, заключается в подготовке к новым, предстоящим составам сервисов, которые потребуют доступа к данным и функциям сотрудников. Эти композиции были в стадии планирования в то время и в настоящее время в производстве.

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

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

Затем группа изучает возможность разделения функциональности в службе Employee на две отдельные службы. С внутренней стороны, есть возможность сделать это относительно чистым способом. В настоящее время сервис инкапсулирует функциональность системы HR ERP и специально разработанного приложения для составления отчетов. Однако, как участник уровня обслуживания сущностей, архитекторы и бизнес-аналитики хотели бы сохранить функциональный контекст, основанный на сущностях бизнеса, в каждой из двух служб, на которые он будет разделен. Поэтому они не хотят принимать решение, основываясь только на текущей архитектуре реализации сервиса.

Они обращаются к группе по информационной архитектуре, отвечающей за ведение основной диаграммы отношений сущностей, для поиска подходящих связанных с сотрудниками сущностей, которые могут составлять основу отдельных служб. Они находят сущность «Записи сотрудников», которая связана с родительской сущностью «Сотрудник». Записи сотрудников представляют историческую информацию о сотрудниках, такую ​​как сверхурочные, больничные, жалобы, продвижения по службе, травмы и т. Д.

Группа анализирует текущие функциональные возможности службы сущностей и дополнительные возможности, которые, возможно, необходимо добавить (например, моделируемые как часть плана инвентаризации услуг, но еще не реализованные). Они также изучают внутренние системы, которые инкапсулируются. Специально разработанное приложение для создания отчетов не предоставляет все необходимые функции для поддержки службы, предназначенной для обработки записей сотрудников. Команде необходимо, чтобы эта служба продолжала получать доступ к системе HR ERP, и, в конечном итоге, для получения доступа к центральному хранилищу данных в будущем понадобятся новые возможности «Записи сотрудников».

С другой стороны, их исходная статистика использования указывает на то, что некоторые из задержек возникли из-за того, что служба Employee была связана с выполнением длительных запросов отчетов. Если бы этот тип функциональности существовал в отдельной службе, основные возможности Сотрудника были бы более масштабируемыми и надежными, а служба Сотрудника была бы «более легкой» и более эффективным участником композиции.

Приняв во внимание все эти факторы, команда считает, что имеет смысл разделить функциональные возможности исторической отчетности на отдельную службу, которая называется «Записи сотрудников». Первая проблема, с которой они сталкиваются, заключается в том, что существующий контракт на обслуживание сотрудников уже используется многими потребительскими программами. Если они перенесут возможности из этого сервиса в другой, они приведут к значительным нарушениям. Для этой ситуации они применяют Proxy Capability (497), как объяснено в следующем примере тематического исследования.

---

---

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

---

Возможность прокси

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

Таблица 16.6.
Сводная информация о профиле для шаблона Proxy Capability.

проблема

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

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

Решение

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

Рис. 16.18. Сохраняя
существующую возможность и позволяя ей выступать в качестве прокси для логики перемещенных возможностей, существующие потребители будут подвержены меньшему воздействию.

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

заявка

Proxy Capability опирается на применение Service Façade (333) в том смысле, что для сохранения затронутых возможностей обслуживания создан фасад. Единственное отличие состоит в том, что вместо вызова логики возможностей, которая все еще является частью той же службы, фасад вызывает возможности, которые теперь являются частью новых услуг ( рисунок 16.19 ).

Рис. 16.19.
Когда существующий потребитель запрашивает операцию службы Invoice, которая была перемещена из-за декомпозиции службы (1), вновь добавленный фасадный компонент пересылает запрос в новое местоположение возможности (2), в этом случае служба отчетов Invoice ,

---

Примечание. Уведомление о завершении (478) также обычно применяется вместе с Proxy Capability для передачи запланированного срока действия возможностей прокси.

---

Воздействие

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

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

Рисунок 16.20
Proxy Capability изменяет структуру сервиса в поддержку создания нового сервиса и поэтому затрагивает несколько шаблонов, связанных со структурой логики сервиса и процессом декомпозиции сервиса.

Кроме того, один этот шаблон не гарантирует, что возможность прокси продолжит обеспечивать такое же поведение и надежность исходной возможности, которую она заменила.

Отношения

Принимая во внимание, что Распределенная Возможность (510) подготавливает услугу для возможного применения Декомпозиции услуг (489), Proxy Capability фактически осуществляет декомпозицию, сохраняя первоначальный контракт на обслуживание.

Это подтверждается разделенным контрактом (401), который позволяет индивидуально настраивать контракты как исходных, так и разложенных сервисов в поддержку прокси-возможности. Фасад службы (333) также играет неотъемлемую роль в том, что он может использоваться для ретрансляции запросов (выступать в качестве прокси) в и из вновь разложенного сервиса.

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

---

Пример тематического исследования

В примере тематического исследования для Decomposition Service (489) мы объяснили, как команда Alleywood решила разделить свою существующую службу Employee на отдельные службы Employee и Employee Record.

Чтобы добиться этого, им нужно найти способ добиться следующего:

1. Создать новую службу учета сотрудников.

2. Переместите соответствующие функции из службы «Сотрудник» в новую службу «Запись сотрудника».

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

Для выполнения шага 1 они моделируют новую службу записи сотрудников, как показано на рисунке 16.21 .

Рис. 16.21.
После некоторого анализа новый кандидат на услугу Записи сотрудника моделируется четырьмя кандидатами в возможности.

Для выполнения шагов 2 и 3 они используют Proxy Capability для каждой из возможностей службы Employee, которую необходимо переместить в службу Rec Employee Record. На рисунке 16.22 показано, как две исходные возможности службы Employee отображаются на четыре из возможностей службы Employee Record.

Рис.
16.22. Возможности AddRecord и GetHistory службы Employee расположены в качестве прокси для возможностей Add, GetRecordReport, GetHoursReport и GetEvalReport Записи сотрудника.

The Employee Record service is eventually designed and delivered as a fully functional, standalone service. However, the Employee service contract remains unchanged, plus additional logic is added in the form of a façade component. This functionality responds to requests for the original AddRecord and GetHistory capabilities and then relays those requests over to the Employee Record. The eventual responses are then received and passed back to the Employee service consumer.

However, one issue remains. In order for the GetHistory operation to work, it must make three calls to the Employee Record service (one to each of the three GetReport operations).

The team considers whether to add a corresponding GetHistory operation to the Employee Record service just for the proxy work that the Employee service must perform. But, they are concerned that the additional operation will be confusing to other consumers. They decide instead to try to accelerate the retirement of the Employee GetHistory operation.

---

Decomposed Capability

How can a service be designed to minimize the chances of capability logic deconstruction?

Table 16.7
Profile summary for the Decomposed Capability pattern.

Problem

Some types of services are more prone to being split after they have been developed and deployed. For example, entity services derive their functional context from corresponding business entities that are documented as part of common information architecture specifications. Often, an entity service context will initially be based around a larger, more significant business entity or even a group of related entities.

This can be adequate for immediate purposes but can eventually result in a number of challenges (Figure 16.23), including the following:

• As the service is extended, many additional capabilities are added because they are all associated with its functional context, leading to a bulky functional boundary that is difficult to govern.

• The service, due to increased popularity as a result of added capabilities or high reuse of individual capabilities, becomes a processing bottleneck.

Figure 16.23
An Invoice entity service (middle) derived from a group of Invoice-related business entities (left) exposes coarse-grained capabilities that are difficult to decompose when service decomposition requirements present themselves. Each of the affected Invoice service capabilities needs to be split up in order to accommodate the new services (right).

Despite a foreknowledge of these challenges, it may still not be possible to create a larger group of more granular services because of infrastructure constraints that restrict the size of potential service compositions. Sometimes an organization needs to wait until its infrastructure is upgraded or its vendor runtime platform matures to the point that it can support complex compositions with numerous participating services. In the meantime, however, the organization cannot afford to postpone the delivery of its services.

Solution

Services can be initially designed with future decomposition requirements in mind, which generally translates into the creation of more granular capabilities. With an entity service, for example, granular capabilities can be aligned better with individual business entities. This way, if the service needs to be decomposed in the future into a collection of services that represent individual business entities, the transition is facilitated by reducing the need to deconstruct capabilities (Figure 16.24).

Figure 16.24
The Invoice service (middle) derived from the same business entities (left) introduced in Figure 16.23 now exposes a series of more granular capabilities, several of which correspond directly to specific business entities. This increases the ease at which subsequent service decomposition can be accomplished. The decomposed services (right) are no longer in conflict because the capabilities affected by the decomposition are clearly mapped to the new services. Those same capabilities also remain in the Invoice service contract (top right) as per Proxy Capability (497).

Application

This pattern introduces more up-front service modeling effort in order to determine the appropriate service capability definitions. Specifically, the following considerations need to be taken into account:

• how the current functional scope can potentially be divided into two or more functional contexts

• how capabilities can be defined for these new functional contexts

This modeling effort follows a process whereby a collection of service candidates are defined in association with the scope of the service in question. These service candidates represent future services that can result from a decomposition of the current service and therefore provide a basis for capability candidates to be defined in support of the decomposition.

---

Note — This pattern differs from Contract Denormalization (414) in that the latter introduces redundant, granular capabilities for the purpose of supporting consumer requirements. Decomposed Capability allows for targeted granular capabilities (which may or may not be redundant) in order to facilitate the long-term evolutionary requirements of the service and the service inventory as a whole.

---

Impacts

The initial service contract that results from applying this pattern can be large and difficult to use. The increased capability granularity can impose performance overhead on service consumers that may be required to invoke the service multiple times to carry out a series of granular functions that could have been grouped together in a coarse-grained capability. This may lead to the need to apply Contract Denormalization (414), which will result in even more capabilities.

Even after the service has been decomposed, the existing consumers of the initial service may still need to be accommodated via proxy capabilities as per Proxy Capability (497), requiring the original service contract to remain for an indefinite period of time.

Also, it is sometimes difficult to predict how a service will be decomposed when initially defining it. There is the constant risk that the service will be populated with fine-grained capabilities that will never end up in other services and may have unnecessarily imposed performance burden upon consumers in the meantime.

Relationships

The key relationship illustrated in Figure 16.25 is between Decomposed Capability and Service Decomposition (489) because this pattern is applied in advance with the foreknowledge that a service will likely need to be decomposed in the future. It can therefore also be viewed as a governance pattern in that its purpose is to minimize the impact of a service’s evolution. For this same reason, it relates to Proxy Capability (497) that will usually end up being applied to one or more of the capabilities decomposed by this pattern.

Figure 16.25
Decomposed Capability prepares a service contract for eventual decomposition, making it closely related to patterns associated with Service Decomposition (489).

As already mentioned, the more fine-grained capabilities introduced by this pattern may require that Contract Denormalization (414) also be applied.

---

Case Study Example

The case study example for Proxy Capability (497) demonstrated how the decomposition of a service can lead to subsequent design issues, even when establishing capabilities that act as proxies for existing consumers. If the capabilities for the newly derived service don’t cleanly match the functional context and granularity of the capabilities of the original service, then awkward and inefficient proxy mapping may result. Depending on how long the retirement of old capabilities can take, the decomposition of a service can actually increase some of the functional burden it was intended to improve.

Let’s focus again on the Employee and Employee Record services explained in the preceding example. If we step back in time when the Employee service was first modeled, we can give the architects and analysts responsible for defining the original service candidate the opportunity to apply Decomposed Capability before proceeding with the physical design and implementation of this service.

In the case of Alleywood, the service would have been based on the two already discussed business entities (Employee and Employee Record) plus a third existing employee-related business entity called Employee Classification. These entities would have determined the capability definition from the beginning in that the original Employee entity service would essentially be viewed as three entity services bundled into one.

Capabilities for this service would have been defined with future decomposition in mind, and the result would have looked a lot like Figure 16.26.

Figure 16.26
The original Employee service modeled to accommodate future decomposition by containing capabilities directly associated with known employee-related business entities. Note that not all of the capability names need to be the same as they will be when the service is decomposed into derived services.

---

Distributed Capability

How can a service preserve its functional context while also fulfilling special capability processing requirements?

Table 16.8
Profile summary for the Distributed Capability pattern.

Problem

Each capability within a service’s functional context represents a body of processing logic. When a service exists in a physically implemented form, its surrounding environment may not be able to fully support all of the processing requirements of all associated capabilities.

For example, there may be a capability with unique performance, security, availability, or reliability requirements that can only be fulfilled through specific architectural extensions and special infrastructure. Other times, it is the increased processing demands on a single capability that can tax the overall service implementation to such an extent that it compromises the performance and reliability of other service capabilities (Figure 16.27).

Figure 16.27
The Consolidate operation of the Invoice Web service is subject to high concurrent usage and long response periods when it is required to perform complex consolidation calculations. These factors regularly lock up server resources and therefore compromise the performance and reliability of other service operations.

The logic supporting such a capability can be split off into its own service implementation. However, this would result in the need to break the original functional context for which the service was modeled.

Solution

Capability logic with special processing requirements is distributed to a physically remote environment. Intermediate processing logic is added to interact with local and distributed service logic on behalf of the single service contract (Figure 16.28).

Figure 16.28
The logic for the Consolidate operation is relocated to a separate physical environment. A service façade component interacts with the consolidation logic on behalf of the Invoice service contract.

Application

This pattern is commonly realized through the application of Service Façade (333) in order to establish the intermediate logic that essentially acts as the controller of a “component composition.” The component(s) representing the distributed capability logic interact with the façade logic via remote access.

Performance requirements can be somewhat streamlined by embedding additional processing logic within the façade so that it does more than just relay request and response message values. For example, the façade logic can contain routines that further parse and extract data from an incoming request message so that only the information absolutely required by the distributed capability logic is transmitted.

An alternative to using Service Façade (333) is Service Agent (543). Event-driven agents can be developed to intercept request messages for a specific service capability. These agents can carry out the validation that exists within the corresponding contract (or perhaps this validation is deferred to the capability logic itself) and then simply route the request message directly to the capability. The same agents can process the outgoing response messages from the capability as well.

Impacts

This pattern preserves the purity of a service’s functional context at the cost of imposing performance overhead. The positioning of the contract as the sole access point for two or more distributed implementations of service logic introduces an increased likelihood of remote access whenever the service is invoked.

If the capability logic was separated to guarantee a certain response time during high volume usage, then this may be somewhat undermined by the remote access requirements. On the other hand, overall service autonomy tends to be positively impacted as the autonomy level of the separated capability logic can be improved as a result of its separation.

Relationships

When structuring a service to support distributed capability processing, the service implementation itself exists like a mini-composition, whereby a façade component takes on the role of both component controller and single access point for the distributed service logic. This is why this pattern has such a strong reliance on Service Façade (333) and why it is supported by Decoupled Contract (401) in particular.

Contract Centralization (409) is also an essential part of the service design because it ensures that the contract will remain the sole access point, regardless of the extent the underlying logic may need to be distributed.

When a distributed capability needs to share access to service-related data, Service Data Replication (350) can be employed to help facilitate this access without the need to introduce intra-service data sharing issues. Additionally, this pattern is often the result of applying Service Refactoring (484) and can therefore be considered a continuation of a refactoring effort, especially when applied after the service’s initial deployment.

Figure 16.29
Distributed Capability supports the internal decomposition of service logic and therefore has relationships with both service logic and contract-related patterns.

---

Case Study Example

The newly deployed Employee Record service that was defined as a result of applying Service Decomposition (489) and Proxy Capability (497) (see the corresponding case study examples) has become increasingly popular. It is currently being reused within eight service compositions and a new development project is going to be requesting its participation in yet another composition.

For this next composition, the project team is asking that new functionality be added to allow the service to produce highly detailed reports that include various record details and statistics relating to employee hours and ratings from past evaluations. To accommodate this requirement, a new capability is added, called GetMasterReport.

This capability is designed into the Web service contract as an operation that is able to receive parameterized input messages and output large documents comprised of various statistical information and record details.

Preliminary tests show that some of the “from” and “to” value ranges accepted by the operation can take minutes to process because the underlying logic is required to access several databases and then perform a series of calculations before it can produce the required consolidated report.

There are concerns that this one capability will tie up the service too often so that its overall scalability will decrease, thereby affecting its reliability. As a result, the team decides to separate the logic for the GetMasterReport operation to a dedicated server. The Employee Record service is equipped with a façade component that relays requests and responses to and from the separated MSTReportGenerator component.

---

---

Note — No diagram is provided for this example because the service architecture would be portrayed almost identically to the Invoice service example from Figure 16.28.

---

This is an excerpt from the book, SOA Design Patterns, authored by Thomas Erl, with additional contributors, published by Prentice Hall, Jan. 2009, as part of The Prentice Hall Service-Oriented Computing Series from Thomas Erl, ISBN 0136135161. Copyright 2009 SOA Sytems Inc. For more info on the patterns catalog, please visit www.soapatterns.org