В программной инженерии каноническая схема представляет собой шаблон проектирования , применяемый в парадигме проектирования, ориентированной на сервисы , целью которой является снижение необходимости в выполнении преобразования модели данных [1] , когда сервисы [2] обмениваются сообщениями, ссылающимися на одну и ту же модель данных. [3]
Взаимодействие между сервисами часто требует обмена бизнес-документами. Для того чтобы потребитель сервиса мог отправить данные (относящиеся к определенному бизнес-объекту, например, заказ на покупку), ему необходимо знать структуру данных, т. е. модель данных. Для этого поставщик сервиса публикует структуру данных, которые он ожидает получить во входящем сообщении от потребителя сервиса. В случае, если сервисы реализуются как веб-сервисы, [4] это будет документ схемы XML. Как только потребитель сервиса узнает требуемую модель данных, он может структурировать данные соответствующим образом. Однако при некоторых условиях может оказаться, что потребитель сервиса уже обладает требуемыми данными, которые относятся к определенному бизнес-документу, но данные не соответствуют модели данных, указанной поставщиком сервиса. Это несоответствие между моделями данных приводит к необходимости преобразования модели данных, чтобы сообщение было преобразовано в требуемую структуру, как предписано поставщиком сервиса. Основываясь на вышеупомянутом примере, вполне возможно, что после обработки полученного бизнес-документа поставщик услуг отправляет обработанный документ обратно потребителю услуг, который снова выполняет преобразование модели данных, чтобы преобразовать обработанный бизнес-документ обратно в модель данных, которую он использует в своей логике для представления бизнес-документа.
Это преобразование модели данных во время выполнения добавляет накладные расходы на обработку и усложняет проектирование композиций услуг. [5] Чтобы избежать необходимости преобразования модели данных, шаблон Canonical Schema диктует использование стандартизированных моделей данных для тех бизнес-документов, которые обычно обрабатываются службами в инвентаре услуг. [6] [7]
Этот шаблон проектирования полностью поддерживается применением принципа проектирования стандартизированного контракта на обслуживание . Принцип проектирования стандартизированного контракта на обслуживание предполагает, что контракты на обслуживание должны быть основаны на стандартизированных моделях данных. Это достигается путем выполнения анализа плана инвентаризации услуг [8] для выявления часто встречающихся деловых документов, которыми обмениваются службы. Затем эти деловые документы моделируются стандартизированным образом. Например, в случае веб-сервисов деловые документы моделируются как схемы XML. После того, как в инвентаризации услуг существует стандартизированный уровень представления данных, различные контракты на обслуживание могут использовать одни и те же модели данных, если им необходимо обмениваться одними и теми же деловыми документами. Это устраняет необходимость в каком-либо преобразовании модели данных и снижает накладные расходы на обработку, связанные с преобразованием модели данных. Это также увеличивает потенциал повторного использования службы, поскольку теперь служба может использоваться без необходимости какой-либо пользовательской логики преобразования модели данных. В некотором смысле применение шаблона канонической схемы снижает необходимость в применении шаблона проектирования преобразования модели данных [9] .
Применение этого шаблона проектирования требует наличия стандартов проектирования [10] , которые делают использование стандартизированных моделей данных обязательным, поскольку простое создание моделей данных не гарантирует их использования. [11] Хотя это просто в принципе, но сложно реализовать, поскольку это требует обязательств со стороны разных проектных групп, что может повлечь за собой дополнительные усилия со стороны каждой группы с точки зрения проектирования решений, которые учитывают стандартизированные модели данных.
В некоторых случаях, либо из-за огромного размера организации, либо из-за сопротивления со стороны различных сегментов предприятия, шаблон проектирования Canonical Schema может потребоваться применить в рамках определенного доменного инвентаря, созданного путем применения шаблона проектирования Domain Inventory . [7]
Схемы должны быть разработаны отдельно от дизайна сервисного контракта, чтобы между ними не было зависимости. [11]