WikiDer > Канонический шаблон схемы - Википедия
В программная инженерия, Каноническая схема это шаблон дизайна, применяется в сервис-ориентированность парадигма дизайна, цель которого - уменьшить потребность в выполнении модель данных [1] трансформация, когда услуги[2] обмениваться сообщениями, которые ссылаются на одну и ту же модель данных.[3]
Обоснование
Взаимодействие между сервисами часто требует обмена деловыми документами. Чтобы потребитель услуги мог отправлять данные (относящиеся к определенному бизнес-объекту, например, заказу на покупку), ему необходимо знать структуру данных, то есть модель данных. Для этого провайдер сервиса публикует структуру данных, которые он ожидает, во входящем сообщении от потребителя сервиса. Если сервисы реализованы как веб-сервисы,[4] это будет документ схемы XML. Как только потребитель сервиса знает требуемую модель данных, он может соответствующим образом структурировать данные. Однако при некоторых условиях может оказаться возможным, что потребитель услуги уже обладает необходимыми данными, которые относятся к конкретному бизнес-документу, но данные не соответствуют модели данных, указанной поставщиком услуг. Это несоответствие между моделями данных приводит к требованию преобразования модели данных, чтобы сообщение преобразовывалось в требуемую структуру в соответствии с требованиями поставщика услуг. Основываясь на вышеупомянутом примере, вполне возможно, что после обработки полученного бизнес-документа поставщик услуг отправит обратно обработанный документ потребителю услуги, который еще раз выполнит преобразование модели данных для преобразования обработанного бизнес-документа обратно в модель данных. которые он использует в своей логике для представления бизнес-документа.
Это преобразование модели данных среды выполнения увеличивает накладные расходы на обработку и усложняет проектирование составов служб.[5] Чтобы избежать необходимости преобразования модели данных, шаблон канонической схемы диктует использование стандартизированных моделей данных для тех бизнес-документов, которые обычно обрабатываются службами в реестре служб.[6][7]
использование
Этот шаблон проектирования полностью поддерживается приложением Стандартный договор на обслуживание принцип конструкции. Принцип разработки стандартных контрактов на обслуживание предполагает, что контракты на обслуживание основываются на стандартизированных моделях данных. Это достигается путем выполнения анализа схемы инвентаризации услуг.[8] для того, чтобы узнать о часто встречающихся деловых документах, которыми обмениваются службы. Затем эти бизнес-документы моделируются стандартизированным образом. Например, в случае веб-служб бизнес-документы моделируются как схемы XML. После того как в реестре услуг существует стандартизированный уровень представления данных, разные контракты на услуги могут использовать одни и те же модели данных, если им необходимо обмениваться одними и теми же бизнес-документами. Это устраняет необходимость в любом преобразовании модели данных и снижает накладные расходы на обработку, связанные с преобразованием модели данных. Это также увеличивает потенциал повторного использования службы, поскольку теперь служба может использоваться без необходимости какой-либо пользовательской логики преобразования модели данных. В некотором смысле, применение шаблона канонической схемы снижает потребность в применении преобразования модели данных.[9] шаблон дизайна.
Соображения
Применение этого шаблона проектирования требует стандартов проектирования[10] которые делают использование стандартизированных моделей данных обязательным, поскольку простое создание моделей данных не гарантирует их использования.[11] Хотя в принципе это просто, но сложно реализовать, так как это требует приверженности со стороны разных проектных групп, что может потребовать дополнительных усилий со стороны каждой команды с точки зрения разработки решений, учитывающих стандартизованные модели данных.
В некоторых случаях, либо из-за огромного размера организации, либо из-за сопротивления со стороны различных сегментов предприятия, шаблон проектирования канонической схемы может потребоваться применить в рамках определенного реестра доменов, созданного с помощью приложения Инвентаризация домена шаблон дизайна.[7]
Схемы необходимо разрабатывать отдельно от дизайна контракта на обслуживание, чтобы между ними не было зависимости.[11]
Смотрите также
Рекомендации
- ^ Структура данных, например. в базе данных структура данных, содержащихся в таблице, представлена схемой таблицы. В случае XML на основе документов, соответствующий документ схемы XML содержит структуру документа XML.
- ^ "Услуги". Архивировано из оригинал на 2012-05-01. Получено 2010-03-17.
- ^ Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. В архиве 2010-03-28 на Wayback Machine [Online], pp. 1-10, 2010 43-я Гавайская международная конференция по системным наукам, 2010. Дата обращения: 30 апреля 2010 г.
- ^ Услуга может быть реализована с использованием любой технологии, если она соответствует сервис-ориентированность руководящие указания.
- ^ «Сервисные композиции». Архивировано из оригинал на 2010-03-11. Получено 2010-03-17.
- ^ «сервисный инвентарь». Архивировано из оригинал на 2010-03-13. Получено 2010-03-17.
- ^ а б Томас Эрл, Хербьорн Вильгельмсен.Шаблон проектирования канонической схемы[В сети]. Дата обращения: 8 апреля 2010 г.
- ^ "Схема инвентаризации услуг". Архивировано из оригинал на 2010-05-11. Получено 2010-03-17.
- ^ «Преобразование модели данных». Архивировано из оригинал на 2010-02-13. Получено 2010-03-17.
- ^ «стандарты дизайна». Архивировано из оригинал на 2010-03-17. Получено 2010-03-17.
- ^ а б Эбен Хьюитт.Поваренная книга Java SOA[постоянная мертвая ссылка][Online] .pp 50. Дата обращения: 25 апреля 2010 г.
- Эрл и др., (2009).Шаблоны проектирования SOA. Прентис Холл. ISBN 0-13-613516-1.
- Томас Эрл (2008).Принципы проектирования сервисов SOA. Прентис Холл. ISBN 0-13-234482-3.