Шаблон канонического протокола
Канонический протокол — это шаблон проектирования , применяемый в рамках , ориентированной на сервисы парадигмы проектирования , который пытается сделать сервисы в рамках реестра сервисов, [1] возможность взаимодействия друг с другом путем стандартизации протоколов связи , используемых службами. Это устраняет необходимость использования протоколов связи, когда службы используют разные протоколы связи. [2]
Обоснование
[ редактировать ]Сервисы, разработанные разными проектными командами, могут основываться на разных механизмах связи. В результате в реестре сервисов могут оказаться разные наборы сервисов, каждый из которых соответствует разному набору протоколов. Когда дело доходит до повторного использования сервисов с разными протоколами связи, требуется какой-то механизм коммуникационного моста. Например, службы, разработанные с использованием протокола обмена сообщениями JMS , несовместимы со службами, использующими .NET Remoting , поэтому для использования этих двух типов служб промежуточного программного обеспечения необходимо наличие некоторой технологии , которая устраняет несоответствие протоколов связи. Помимо дополнительных затрат, использование такой технологии моста увеличивает задержку и накладные расходы на связь. Это делает сервис менее многоразовым и компонуемым. [3] ресурс и противоречит принципам компонуемости сервисов .
Чтобы разработать реестр сервисов, в котором все сервисы будут совместимы друг с другом, чтобы их можно было объединить в разные решения, применение шаблона канонического протокола требует стандартизации протоколов связи, используемых сервисами. Когда все службы используют один и тот же протокол связи, необходимость в технологии моста устраняется, и связь между службами становится более упорядоченной. [4]
Использование
[ редактировать ]
Сервисы, разработанные с использованием разных протоколов связи, не могут взаимодействовать друг с другом.
Сервисы, разработанные с использованием одних и тех же протоколов связи, могут взаимодействовать друг с другом и, следовательно, могут использоваться в нескольких композициях сервисов.
Применение этого шаблона проектирования требует выбора технологической архитектуры, которая обеспечивает общую структуру связи, чтобы все службы в инвентаре могли взаимодействовать друг с другом, используя один и тот же протокол связи. Это зависит от того, как будут использоваться сервисы в реестре сервисов. Если службы будут только частью составов служб, которые всегда используют определенный протокол связи (по соображениям эффективности и безопасности), то все службы в этом списке служб могут быть построены на таком протоколе связи, даже если он не является наиболее широко используемый протокол.
Шаблон «Канонический протокол» Томаса Эрла отвечает на вопрос: «Как можно спроектировать сервисы, чтобы избежать соединения протоколов?» [5] Проблема в том, что сервисы, поддерживающие различные коммуникационные технологии, нарушают совместимость, ограничивают количество потенциальных потребителей и приводят к необходимости принятия нежелательных мер по объединению протоколов. Решение состоит в том, чтобы архитектура установила единую коммуникационную технологию в качестве единственной или основной среды, с помощью которой могут взаимодействовать службы. Таким образом, протоколы связи (включая версии протоколов), используемые в границах инвентаря сервисов, стандартизированы для всех сервисов (см. диаграмму).
Одним из наиболее зрелых и широко используемых механизмов связи является платформа веб-сервисов. Помимо выбора структуры связи, необходимо также стандартизировать фактические протоколы сообщений. Например, создаются ли веб-сервисы с использованием SOAP через HTTP или просто с использованием сервисов RESTful . Аналогично, при стандартизации веб-сервисов на основе SOAP необходимо согласовать конкретную версию протокола SOAP, например, SOAP v 1.1 или SOAP v 1.2.
Соображения
[ редактировать ]Чтобы стандартизировать протокол связи, его характеристики необходимо сравнить с требованиями взаимодействия служб, включая безопасность, эффективность и поддержку транзакций. Например, в случае веб-служб, если композиция службы требует явной поддержки транзакций, тогда SOAP через HTTP будет лучшим выбором, чем использование служб RESTful.
В некоторых случаях, в зависимости от технологии, используемой для создания службы, может оказаться возможным поддерживать два разных набора протоколов, чтобы сделать службу доступной для разных типов потребителей службы (шаблон проектирования двойных протоколов). [6] ). Например, с помощью WCF одну и ту же службу можно настроить для HTTP и TCP/IP одновременного использования протоколов .
При выборе коммуникационной среды необходимо учитывать зрелость, масштабируемость и любые затраты на лицензирование, поскольку создание сервисов с использованием протокола, который устареет в ближайшем будущем, повлияет на возможность повторного использования таких сервисов и потребует значительного времени и усилий. с целью редизайна сервиса.
Ссылки
[ редактировать ]- Примечания
- ^ Сервисный инвентарь. Архивировано 13 марта 2010 г. в Wayback Machine.
- ^ Мэтью Дэйли. Проектирование архитектуры программного обеспечения. Сервис-ориентированные архитектуры (Часть II). Архивировано 24 июля 2011 г. на Wayback Machine [Онлайн]. Дата доступа: 25 апреля 2010 г.
- ↑ Состав службы . Архивировано 11 марта 2010 г. в Wayback Machine.
- ^ Мауро. и др. Сервис-ориентированная интеграция устройств: анализ шаблонов проектирования SOA. [Онлайн], стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 30 апреля 2010 г. Архивировано 28 марта 2010 г., в Wayback Machine.
- ^ Шаблоны SOA - Канонический протокол. Архивировано 14 декабря 2009 г. в Wayback Machine.
- ↑ Шаблон проектирования двойных протоколов. Архивировано 14 декабря 2009 г., в Wayback Machine.
- Источники
- Томас Эрл и др. (2009). Шаблоны проектирования SOA . Прентис Холл. ISBN 978-0-13-613516-6 .