Стандартизированный договор на обслуживание
Стандартизированный контракт на обслуживание — это программного обеспечения . принцип проектирования [1] применяется в рамках ориентированной на обслуживание парадигмы проектирования, , чтобы гарантировать, что контракты на обслуживание [2] в сервисном инвентаре [3] (предприятие или домен) придерживаются одного и того же набора стандартов проектирования. [4] Это облегчает стандартизацию контрактов на обслуживание по всему спектру услуг. [5]
Цель
[ редактировать ]Гибкость , обеспечиваемая сервис-ориентированной архитектурой (SOA), обычно измеряется уровнем возможности повторного использования содержащихся в ней сервисов. Однако возможность повторного использования напрямую связана с тем, как контракт службы определяет возможности службы. Служба, построенная на потенциально повторно используемом функциональном контексте. [6] но контракт, который не передает эту возможность повторного использования правильно, не реализует свой потенциал повторного использования.
В рамках сервис-ориентированных решений контракт службы представляет собой фундаментальный артефакт, поскольку это единственная среда, посредством которой службы взаимодействуют друг с другом или с другими потребительскими программами. Это создает острую необходимость стандартизировать сервисные контракты, чтобы сделать сервисы повторно используемыми и компонуемыми в максимально возможной степени. Для достижения этой цели необходимо применять принцип проектирования стандартизированных контрактов на обслуживание, поскольку его применение приводит к созданию стандартизированных контрактов на обслуживание, основанных на стандартах проектирования. [7] как указано в перечне услуг.
Одна из его целей — уменьшить потребность в преобразованиях данных при взаимодействии двух сервисов друг с другом, чего можно достичь, если в контрактах сервисов используются стандартизированные модели данных, например схемы XML, если сервисы реализованы как веб-сервисы . Это также помогает сделать услуги более совместимыми. Другая важная цель этого шаблона проектирования — использовать стандартизированный способ выражения возможностей сервисов, чтобы их назначение и возможности можно было легко понять во время разработки. [8]
Приложение
[ редактировать ]Договор на техническое обслуживание [9] обычно состоит из документа WSDL , схем XML и документов политики. Следовательно, этот принцип необходимо применять в трех областях контракта на оказание услуг, как описано ниже:
Стандартизация функциональных выражений
[ редактировать ]Операции службы необходимо определять с использованием стандартизированных соглашений об именах. Это также применимо к именам составляющих входных и выходных сообщений и соответствующим им именам типов. Это помогает улучшить правильную интерпретацию контракта службы, что, в свою очередь, увеличивает возможность повторного использования службы и ее функциональную совместимость. Когда в контрактах на обслуживание четко указаны их возможности, вероятность дублирования услуг также снижается.
Стандартизация модели данных
[ редактировать ]Две службы, обменивающиеся сообщениями на основе данных одного и того же типа (например, заказа на покупку), могут моделировать эти данные в соответствии с разными схемами, что требует преобразования модели данных. Это явно увеличивает накладные расходы и препятствует взаимодействию и повторному использованию сервисов. Чтобы избежать этой трансформации, принцип стандартизированного контракта на обслуживание требует стандартизированных моделей данных, что дополнительно помогает создать стандартизированную архитектуру представления данных, которую можно повторно использовать на предприятии для определения возможностей стандартизированного обслуживания. Централизация схемы напрямую поддерживает цели стандартизации модели данных. [10] шаблон проектирования, который дополнительно поддерживает создание централизованно управляемых схем.
Стандартизация политики
[ редактировать ]Политики обслуживания представляют собой условия использования сервиса. Таким образом, чтобы сервис можно было использовать повторно, его поведенческие требования должны быть последовательно выражены с использованием стандартизированных выражений политики, основанных на стандартных отраслевых словарях. Этот тип стандартизации еще больше способствует отделению политик от контрактов на обслуживание в отдельные политические документы, что облегчает централизованное управление. В некоторых случаях две политики, хотя и синтаксически разные, могут означать одно и то же, поэтому стандарты проектирования должны диктовать приемлемую структуру политики.
Соображения
[ редактировать ]Применение этого принципа проектирования зависит от стандартов проектирования на уровне сервисного инвентаря. Это требует дополнительных ресурсов, как времени, так и усилий. Во-вторых, чтобы эффективно применить этот принцип проектирования, реальный контракт должен быть физически изолирован от логики и реализации сервиса, чтобы его можно было основывать на отраслевых стандартах. Этого можно достичь путем применения отдельного контракта. [11] шаблон дизайна. Кроме того, необходимо следовать подходу «сначала контракт», чтобы в базовой логике использовались только стандартизированные модели данных. Более того, требование к централизованным моделям данных может привести к передаче избыточных данных между службами, поскольку фактические данные, необходимые службе, могут представлять собой лишь подмножество данных, определенных в стандартизированной схеме, наложенной на службу.
Ссылки
[ редактировать ]- ^ «Принцип проектирования» . Архивировано из оригинала 29 апреля 2010 г. Проверено 7 марта 2010 г.
- ^ «Договоры на оказание услуг» . Архивировано из оригинала 1 мая 2012 г. Проверено 9 марта 2010 г.
- ^ «Инвентаризация услуг» . Архивировано из оригинала 13 марта 2010 г. Проверено 9 марта 2010 г.
- ^ Подвал, Войцех; Стрыковский, Сергиуш. «Электронное правительство на основе облачных вычислений и сервис-ориентированной архитектуры». Материалы 3-й международной конференции по теории и практике электронного управления . ИКЕГОВ '09. стр. 5–10. дои : 10.1145/1693042.1693045 . ISBN 978-1-60558-663-2 .
- ^ Майкл Пулен. Эволюция принципов ориентации на обслуживание: Контракт на обслуживание, часть 2. Архивировано 29 сентября 2011 г. на Wayback Machine . Дата обращения: 12 апреля 2010 г.
- ^ Граница службы, т. е. тип функций, предоставляемых службой.
- ^ Тост. и др. Рекомендации по использованию технологий контрактов веб-сервисов. Архивировано 3 октября 2012 г. на Wayback Machine . Дата обращения: 12 апреля 2010 г.
- ^ Коу-Кай Лин. Предварительное исследование сервис-ориентированной миграции для мелкомасштабной миграции. Архивировано 15 августа 2011 г. в Wayback Machine . Дата обращения: 10 апреля 2010 г.
- ^ Поскольку сервисы обычно реализуются как веб-сервисы, эта статья посвящена применению этого принципа проектирования в контексте веб-сервисов.
- ^ «Шаблон централизации схемы» . Архивировано из оригинала 11 февраля 2010 г. Проверено 18 февраля 2010 г.
- ^ «Шаблон несвязанного контракта» . Архивировано из оригинала 13 февраля 2010 г. Проверено 18 февраля 2010 г.
- Мауро. и др. Сервис-ориентированная интеграция устройств: анализ шаблонов проектирования SOA. , стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
- Эрл, Томас (2008). SOA-принципы проектирования сервисов . Прентис Холл. ISBN 978-0-13-234482-1 .
- Пол-Александру Истоан. Линии программных продуктов и сервис-ориентированные архитектуры: можно ли их соединить . Дата обращения: 10 апреля 2010 г.
- Юсеф Ашбани. Многоагентная платформа для разработки адаптируемых и открытых систем обслуживания . Дата обращения: 10 апреля 2010 г.
- Кьель-Сверре Ериярви. Модель срока действия контракта SOA . Дата обращения: 12 апреля 2010 г.