Шаблон канонической схемы

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

Обоснование

Взаимодействие между сервисами часто требует обмена бизнес-документами. Для того чтобы потребитель сервиса мог отправить данные (относящиеся к определенному бизнес-объекту, например, заказ на покупку), ему необходимо знать структуру данных, т. е. модель данных. Для этого поставщик сервиса публикует структуру данных, которые он ожидает получить во входящем сообщении от потребителя сервиса. В случае, если сервисы реализуются как веб-сервисы, [4] это будет документ схемы XML. Как только потребитель сервиса узнает требуемую модель данных, он может структурировать данные соответствующим образом. Однако при некоторых условиях может оказаться, что потребитель сервиса уже обладает требуемыми данными, которые относятся к определенному бизнес-документу, но данные не соответствуют модели данных, указанной поставщиком сервиса. Это несоответствие между моделями данных приводит к необходимости преобразования модели данных, чтобы сообщение было преобразовано в требуемую структуру, как предписано поставщиком сервиса. Основываясь на вышеупомянутом примере, вполне возможно, что после обработки полученного бизнес-документа поставщик услуг отправляет обработанный документ обратно потребителю услуг, который снова выполняет преобразование модели данных, чтобы преобразовать обработанный бизнес-документ обратно в модель данных, которую он использует в своей логике для представления бизнес-документа.
Это преобразование модели данных во время выполнения добавляет накладные расходы на обработку и усложняет проектирование композиций услуг. [5] Чтобы избежать необходимости преобразования модели данных, шаблон Canonical Schema диктует использование стандартизированных моделей данных для тех бизнес-документов, которые обычно обрабатываются службами в инвентаре услуг. [6] [7]

Использование

Диаграмма А
Диаграмма A.
Сервис A использует другую модель данных по сравнению с сервисом B для того же бизнес-документа. При обмене сообщениями необходимо выполнить преобразование модели данных во время выполнения.
Диаграмма Б
Диаграмма B.
Оба сервиса используют одну и ту же модель данных для представления конкретного бизнес-документа. В результате при обмене сообщениями не требуется преобразования модели данных.

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

Соображения

Применение этого шаблона проектирования требует наличия стандартов проектирования [10] , которые делают использование стандартизированных моделей данных обязательным, поскольку простое создание моделей данных не гарантирует их использования. [11] Хотя это просто в принципе, но сложно реализовать, поскольку это требует обязательств со стороны разных проектных групп, что может повлечь за собой дополнительные усилия со стороны каждой группы с точки зрения проектирования решений, которые учитывают стандартизированные модели данных.
В некоторых случаях, либо из-за огромного размера организации, либо из-за сопротивления со стороны различных сегментов предприятия, шаблон проектирования Canonical Schema может потребоваться применить в рамках определенного доменного инвентаря, созданного путем применения шаблона проектирования Domain Inventory . [7]
Схемы должны быть разработаны отдельно от дизайна сервисного контракта, чтобы между ними не было зависимости. [11]

Смотрите также

Ссылки

  1. ^ Структура данных, например, в базе данных, структура данных, содержащихся в таблице, представлена ​​схемой таблицы. В случае документов на основе XML соответствующий документ схемы XML содержит структуру документа XML.
  2. ^ "Услуги". Архивировано из оригинала 2012-05-01 . Получено 2010-03-17 .
  3. ^ Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. Архивировано 28.03.2010 в Wayback Machine [Online], стр. 1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Дата обращения: 30 апреля 2010 г.
  4. ^ Услуга может быть реализована с использованием любой технологии, если она соответствует принципам ориентации на услуги .
  5. ^ "Сочинения о службе". Архивировано из оригинала 2010-03-11 . Получено 2010-03-17 .
  6. ^ "service inventory". Архивировано из оригинала 2010-03-13 . Получено 2010-03-17 .
  7. ^ ab Томас Эрл , Хербьорн Вильгельмсен. Шаблон проектирования канонической схемы [Онлайн]. Дата обращения: 8 апреля 2010 г.
  8. ^ "Service Inventory Blueprint". Архивировано из оригинала 2010-05-11 . Получено 2010-03-17 .
  9. ^ "Data Model Transformation". Архивировано из оригинала 2010-02-13 . Получено 2010-03-17 .
  10. ^ "стандарты проектирования". Архивировано из оригинала 2010-03-17 . Получено 2010-03-17 .
  11. ^ ab Eben Hewitt.Java SOA Cookbook [ постоянная нерабочая ссылка ‍ ] [Онлайн]. стр. 50. Дата обращения: 25 апреля 2010 г.
  • Концепции SOA
  • Глоссарий терминов SOA
  • Шаблоны проектирования SOA
Получено с "https://en.wikipedia.org/w/index.php?title=Canonical_schema_pattern&oldid=1031755312"