WikiDer > Стандартный договор на обслуживание

Standardized service contract

В стандартный контракт на обслуживание это программного обеспечения принцип конструкции[1] применяется в сервис-ориентированность парадигма дизайна чтобы гарантировать, что сервисные контракты[2] в перечне услуг[3] (предприятие или домен) придерживаются того же набора стандартов проектирования.[4] Это упрощает стандартизацию сервисных контрактов для всего сервисного инвентаря.[5]

Цель

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

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

Одна из его целей - снизить потребность в преобразовании данных, поскольку две службы взаимодействуют друг с другом, что может быть достигнуто, если в контрактах на службы используются стандартизированные модели данных, например Схемы XML если услуги были реализованы как веб-сервисы. Это также помогает сделать сервисы более совместимыми. Еще одна важная цель этого шаблона проектирования - использовать стандартизованный способ выражения возможностей служб, чтобы их цель и возможности можно было легко понять во время разработки.[8]

Заявление

Договор на техническое обслуживание [9] обычно состоит из WSDL документ, схемы XML и документ (ы) политики. Следовательно, этот принцип необходимо применять в трех областях контракта на оказание услуг, как описано ниже:

Стандартизация функциональных выражений

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

Стандартизация модели данных

Две службы, обменивающиеся сообщениями на основе одного и того же типа данных, например, заказа на покупку, могут моделировать эти данные в соответствии с разными схемами, что требует преобразования модели данных. Это явно увеличивает накладные расходы и препятствует взаимодействию и повторному использованию сервисов. Чтобы избежать этого преобразования, принцип стандартизированного контракта на обслуживание требует стандартизованных моделей данных, что дополнительно помогает создать стандартизированную архитектуру представления данных, которую можно повторно использовать на предприятии для определения возможностей стандартизированных услуг. Централизация схемы напрямую поддерживает цели стандартизации модели данных.[10] шаблон проектирования, который дополнительно поддерживает создание схем с централизованным управлением.

Стандартизация политики

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

Соображения

Применение этого принципа проектирования зависит от стандартов проектирования на уровне инвентаризации услуг. Это требует дополнительных ресурсов с точки зрения времени и усилий. Во-вторых, для эффективного применения этого принципа проектирования фактический контракт должен быть физически изолирован от логики и реализации сервиса, чтобы он мог быть основан на отраслевых стандартах. Это может быть достигнуто путем применения несвязанного контракта.[11] шаблон дизайна. Кроме того, необходимо придерживаться подхода «сначала контракт», чтобы базовая логика использовала только стандартизованные модели данных. Кроме того, потребность в централизованных моделях данных может заканчиваться передачей избыточных данных между службами, поскольку фактические данные, в которых нуждается служба, могут быть только подмножеством данных, определенных в стандартизированной схеме, наложенной на службу.

Рекомендации

  1. ^ Принцип дизайна
  2. ^ Сервисные контракты
  3. ^ Инвентарь услуг
  4. ^ Cellary, Войцех; Стрыковский, Сергиуш. «Электронное правительство на основе облачных вычислений и сервис-ориентированной архитектуры». Материалы 3-й международной конференции по теории и практике электронного управления. ИСЕГОВ '09. С. 5–10. Дои:10.1145/1693042.1693045. ISBN 978-1-60558-663-2.
  5. ^ Майкл Пулен.Эволюция принципов сервисной ориентации: Сервисный договор, часть 2Дата обращения: 12 апреля 2010 г.
  6. ^ Граница услуги, т. Е. Тип функций, которые предоставляет услуга.
  7. ^ Tost. и другие.Рекомендации по использованию контрактных технологий веб-службДата обращения: 12 апреля 2010 г.
  8. ^ ко-Кай Линь.Предварительное исследование сервис-ориентированной миграции для маломасштабной миграции.Дата обращения: 10 апреля 2010 г.
  9. ^ Поскольку службы обычно реализуются как веб-службы, в этой статье основное внимание уделяется применению этого принципа проектирования в контексте веб-служб.
  10. ^ Шаблон централизации схемы
  11. ^ Разъединенный шаблон контракта

внешняя ссылка