Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

 Если сервис будет развертываться в закрытой сети, можно использовать более

эффективный протокол связи Transmission Control Protocol (TCP). Если сервис будет

развертываться в публичной сети, следует выбирать протокол Hypertext Transfer

Protocol (HTTP).

 Выработайте стратегию обработки ненадежной или неустойчивой связи, возможно, с

применением кэширования сообщений с последующей их передачей при

возобновлении соединения, а также обработки асинхронных вызовов. Примите

решение о том, будет ли связь односторонней или двухсторонней, и есть ли

необходимость в применении шаблонов Duplex, Request Response и Request-Reply.

 Используйте динамический подход к формированию URL-адреса конечных точек для

обеспечения максимальной гибкости и определите, как будете проверять адреса

конечных точек в сообщениях.

 Выберите соответствующие протоколы связи и обеспечьте защиту данных,

передаваемых по каналам связи, с помощью шифрования и/или цифровых подписей.

Более подробно протоколы и техники связи рассматриваются в главе 18, «Взаимодействие и

обмен сообщениями».

Слой доступа к данным

Слой доступа к данным сервисного приложения включает функциональность доступа к

данным для взаимодействия с внешними источниками данных. Этими источниками могут быть

базы данных, другие сервисы, файловая система, списки SharePoint или любые другие

приложения, работающие с данными. Согласованность данных является основным условием

стабильности и целостности реализации сервиса, неспособность проверить

непротиворечивость данных, получаемых сервисом, может привести к размещению в

хранилище недействительных данных, к неожиданным исключениям и брешам в системе

защиты. Поэтому в реализацию сервиса всегда должны быть включены проверки

непротиворечивости данных. При проектировании слоя доступа к данным руководствуйтесь

следующими рекомендациями:

 Слой доступа к данным по возможности должен развертываться на одном уровне с

бизнес-слоем. Развертывание слоя доступа к данным на другом физическом уровне

потребует сериализации объектов при пересечении ими физических границ.

 Всегда используйте абстракцию при реализации интерфейса слоя доступа к данным.

Как правило, это обеспечивается применением шаблонов Data Access или Table Data

Gateway, в которых типы входных и выходных данных определены.

 Для каждой таблицы или представления базы данных создайте класс для реализации

простых операций Create, Read, Update и Delete (CRUD). Это обеспечивает шаблон

Table Module, в котором каждой таблице поставлен в соответствие класс с

операциями, взаимодействующими с этой таблицей. Спланируйте обработку

транзакций.

 Избегайте применения олицетворения или делегирования для доступа к базе данных,

используйте для этого общую сущность, обеспечивая при этом данные удостоверения

пользователя, чтобы процессы протоколирования и аудита могли ассоциировать

пользователей с осуществляемыми ими действиями.

Более подробно реализация слоя доступа к данным обсуждается в главе 8, «Рекомендации по

проектированию слоя доступа к данным».

Управление исключениями

Проектирование эффективной стратегии управления исключениями имеет большое значения

для обеспечения безопасности и надежности сервисного приложения, в противном случае,

оно будет уязвимым для атак Отказа в обслуживании (Denial of Service, DoS) и может допустить

разглашение конфиденциальных или критически важных данных. Формирование и обработка

исключений является ресурсоемкой операцией, поэтому важно, чтобы стратегия управления

исключениями разрабатывалась с учетом влияния на производительность. Хорошим подходом

является проектирование централизованного механизма управления исключениями и

протоколирования и предоставление контрольных точек, поддерживающих

инструментирование и централизованный мониторинг, что облегчит работу системных

администраторов. При проектировании стратегии управления исключениями

руководствуйтесь следующими рекомендациями:

 Убедитесь, что перехватываете необрабатываемые исключения и очищаете ресурсы

после возникновения исключений. Не допускайте разглашения конфиденциальных

данных в исключениях сервисах, файлах журналов и файлах аудита.

 Перехватывайте только те исключения, которые можете обработать, например, для

удаления из них конфиденциальных данных или введения дополнительных данных.

Не используйте исключения для управления логикой приложения. Избегайте

использования собственных исключений, когда в них нет крайней необходимости.

 Используйте SOAP-элементы Fault или специальные расширения для возвращения

данных исключения вызывающей стороне.

Более подробно проектирование стратегии управления исключениями рассматривается в

главе 17, «Сквозная функциональность».

Структура сообщения

Данные, которыми обмениваются сервис и потребитель при взаимодействии, должны быть

заключены в сообщение. Формат этого сообщения определяется типами поддерживаемых

операций. Например, может происходить обмен документами, выполнение команд или

формирование событий. При использовании медленных каналов доставки в сообщение также

необходимо включить сведения о сроке действия. При проектировании структуры сообщений

руководствуйтесь следующими рекомендациями:

 Выбирайте соответствующие шаблоны для структуры сообщения (такие как Command,

Document, Event и Request-Response).

 Разделяйте очень большие объемы данных на меньшие блоки и отправляйте их

последовательно.

 Включайте в сообщения с ограничением по времени действия сведения о сроке

действия. Сервис должен игнорировать сообщения, срок действия которых истек.

Конечная точка сообщения

Конечная точка сообщения представляет подключение, используемое приложением для

взаимодействия с сервисом. Реализация интерфейса сервиса обеспечивает конечную точку

сообщения. При проектировании реализации сервиса должен быть учтен тип потребляемого

сообщения. Кроме того, необходимо предусмотреть ряд сценариев, связанных с обработкой

сообщений. При проектировании конечных точек сообщений руководствуйтесь следующими

рекомендациями:

 Выбирайте соответствующие шаблоны конечных точек сообщений (такие как

Gateway, Mapper (Преобразователь), Competing Consumer и Message Dispatcher).

 При проектировании предусмотрите сценарии без подключения. Например, для

обеспечения гарантированной доставки может понадобиться реализовать

кэширование или сохранение сообщений для последующей их доставки. Не

допускайте попыток обращения к конечным точкам в условиях отсутствия

подключения.

 Если должны приниматься не все сообщения, реализуйте фильтр для обработки

только определенных сообщений.

 Обеспечьте идемпотентность интерфейса сервиса. Идемпотентность – это ситуация,

когда от одного о того же потребителя могут поступать дублирующиеся сообщения,

но обрабатываться должно только одно из них. Иначе говоря, идемпотентная

конечная точка гарантирует, что из всех дублирующихся сообщений будет

обработано только одно, все остальные будут проигнорированы.

 Обеспечьте коммутативность. Коммутативность – это ситуация, когда сообщения

могут поступать в произвольном порядке. Иначе говоря, коммутативная конечная

точка гарантирует, что поступающие в произвольном порядке сообщения будут

сохранены и впоследствии обработаны в правильном порядке.

Защита сообщений

При обмене конфиденциальными данными между сервисом и его потребителем необходимо

обеспечить защиту сообщений. Для этого может использоваться защита на транспортном

уровне (посредством протоколов IPSec или SSL) или защита на уровне сообщения

(посредством шифрования и цифровых подписей). При проектировании стратегии защиты

сообщений руководствуйтесь следующими рекомендациями:

 Используйте безопасность на уровне сообщения, если требуется обеспечить сквозную

безопасность и существует вероятность наличия между сервисом и вызывающей

стороной посредников, таких как серверы и маршрутизаторы. Безопасность на уровне

сообщения помогает защитить конфиденциальные данные в сообщениях путем их

шифрования. Применение цифровых подписей поможет защититься от отказа

пользователей от действий и повреждения или подделки сообщений. Тем не менее,

не забывайте, что все меры по обеспечению безопасности негативно сказываются на

производительности.

 Если взаимодействия между сервисом и потребителем осуществляются без

посредников, таких как другие серверы и маршрутизаторы, можно использовать

защиту на транспортном уровне, такую как протоколы IPSec или SSL. Однако если

сообщение проходит через одного или более посредников, всегда должны

применяться меры защиты на уровне сообщения. Если используется защита на

транспортном уровне, сообщение дешифруется и вновь шифруется на каждом

посреднике, что представляет угрозу безопасности.

 Для обеспечения максимальной безопасности используйте оба типа защиты, на

транспортном уровне и на уровне сообщения. Защита на транспортном уровне

поможет защищать данные заголовков, которые не могут быть зашифрованы при

использовании защиты на уровне сообщения.

 При проектировании сервисов для экстрасети или типа «бизнес-бизнес» используйте

косвенную аутентификацию на основе сообщений с сертификатами X.509. В сценарии

«бизнес-бизнес» сертификат должен быть выпущен коммерческим центром

сертификации. Для сервисов экстрасети можно применять сертификаты, выпущенные

сервисом сертификации организации.

Преобразование сообщений

При передаче сообщений между сервисом и потребителем существует множество сценариев,

когда сообщение требуется преобразовать в формат, понятный потребителю. Обычно это

происходит в случаях, когда потребители, не имеющие возможности использовать обмен

сообщениями, должны обрабатывать данные, извлекаемые из системы, использующей обмен

сообщениями. Для обеспечения доступа к каналу сообщений для таких потребителей могут

использоваться адаптеры и трансляторы для преобразования данных сообщения в формат,

понятный каждому потребителю. При проектировании стратегии преобразования сообщений

руководствуйтесь следующими рекомендациями:

 Выясните, есть ли необходимость в преобразовании. Если такая необходимость

имеется, выберите походящие шаблоны для преобразования сообщений. Например,

шаблон Normalizer может использоваться для преобразования семантически

эквивалентных сообщений в общий формат. Используйте каноническую модель

только в случае крайней необходимости.

 Обеспечьте преобразования в соответствующем месте, чтобы избежать повторных

обработок и ненужных издержек.

 Определяйте формат сообщения с помощью метаданных и храните эти метаданные

во внешнем хранилище.

 Применяйте такие механизмы, как BizTalk Server, который может осуществлять

преобразования сообщений для широкой номенклатуры форматов и типов клиентов.

Шаблоны обмена сообщениями

Шаблон обмена сообщениями определяет взаимодействие между сервисом и его

потребителем. Это взаимодействие представляет контракт между сервисом и потребителем.

Консорциум W3C описывает два шаблона для SOAP-сообщений: Request-Response и SOAP

Response. Другая группа стандартизации, OASIS, выработала для сервисов Язык выполнения

бизнес-процессов (Business Process Execution Language, BPEL). BPEL определяет процесс для

обмена сообщениями бизнес-процесса. Кроме того, другие организации определяют

специальные шаблоны обмена сообщениями для обмена сообщениями бизнес-процессов.

При проектировании шаблонов обмена сообщениями руководствуйтесь следующими

рекомендациями:

 Выбирайте шаблоны, соответствующие имеющимся требованиям и не вводящие

дополнительных сложностей. Например, не используйте сложный шаблон обмена

сообщениями бизнес-процесса, если достаточно шаблона Request-Response. Для

однонаправленного обмена сообщениями используйте шаблон Fire and Forget.

 При использовании техник моделирования бизнес-процесса существует опасность

создания шаблонов обмена на основании этапов процесса. Шаблоны должны

поддерживать операции, объединяющие этапы процесса.

 Не изобретайте собственные, а применяйте существующие стандарты для шаблонов

обмена сообщениями. Это обеспечит создание основанного на стандартах

интерфейса, который будет понятен многим потребителям. Иначе говоря,

потребители охотнее будут взаимодействовать с основанными на стандартах

контрактами, а не изучать и принимать нестандартные контракты.

Передача репрезентативного состояния

Передача репрезентативного состояния (Representational State Transfer, REST) – это

архитектурный стиль, основанный на HTTP, работа которого во многом напоминает Веб-

приложение. Но вместо пользователя, взаимодействующего с Веб-страницами и

перемещающегося по ним, в этом случае приложения взаимодействуют и перемещаются по

REST-ресурсам, используя ту же семантику, что и Веб-приложение. В REST ресурс

идентифицируется Унифицированным идентификатором ресурса (Uniform Resource Identifier,

URI), и действия, которые могут быть осуществлены по отношению к ресурсу, описываются с

помощью HTTP-команд, таких как GET, POST, PUT и DELETE. Взаимодействие с REST-сервисом

происходит путем выполнения HTTP-операций по отношению к URI, который обычно

представлен в форме URL. В результате операции возвращается представление текущего

состояния этого ресурса. Кроме того, результат может включать ссылки на другие ресурсы, к

которым можно перейти из текущего ресурса.

Наиболее распространенное заблуждение о REST в том, что он подходит только для CRUD-

операций с ресурсом. REST может использоваться с любым сервисом, который может быть

представлен как конечный автомат. Иначе говоря, если сервис может быть разложен на

различимые состояния, такие как извлечен и обновлен, вы можете преобразовать эти

состояния в действия и продемонстрировать, как каждое из состояний может привести к

одному или более состояниям. Вспомните, как UI Веб-приложения представляет конечный

автомат. При доступе к странице отображаемые данные представляют текущее состояние этих

данных. Пользователь может иметь возможность изменять это состояние, обновляя поля

формы через операцию POST или переходя к другой странице, используя ссылки, включенные

в текущую страницу. Сервис, использующий REST, работает по такой же схеме в том смысле,

что приложение может осуществлять операцию GET над ресурсом для получения его текущего

состояния, менять состояние ресурса с помощью операции PUT или переходить к другому

ресурсу, используя ссылки, предоставляемые текущим ресурсом.

В сервисах, поддерживающих REST, имеется и состояние приложения, и состояние ресурса.

Клиент сохраняет состояние всего приложения, тогда как на сервере хранится только

состояние ресурса. Каждый запрос клиента к серверу должен включать все необходимые

серверу данные для полного понимания данного запроса. Иначе говоря, клиент должен

передавать в запросе все данные, касающиеся состояния приложения. Затем, на основании

ответов сервера, клиент может принимать решения о том, как изменять состояние ресурса.

Передача состояния приложения при каждом запросе обеспечивает возможность

масштабирования приложения, поскольку в этом случае можно добавлять множество

идентичных Веб-серверов и балансировать нагрузку таким образом, что клиенту нет

необходимости привязываться к одному конкретному серверу или состоянию любого

совместно используемого приложения.

REST-сервис обладает качествами безопасности и идемпотентности. Безопасность означает

способность многократно повторять запрос и получать один и тот же результат без каких-либо

побочных эффектов. Под идемпотентностью подразумевается такое поведение, когда

многократное повторение вызова приводит к тем же результатам, что и однократный вызов.

Эти качества повышают устойчивость к ошибкам и надежность, потому что, даже несмотря на

ненадежность HTTP, вы можете безопасно повторять запрос, если сервис не отвечает или

возвращает ошибку.

При проектировании REST-ресурсов руководствуйтесь следующими рекомендациями:

 Используйте диаграмму состояния для моделирования и описания ресурсов, которые

будет поддерживать REST-сервис. Не используйте состояние сеанса в REST-сервисе.

 Выработайте подход для идентификации ресурсов. Хорошей практикой является

использование значимых имен начальных точек и уникальных идентификаторов REST

в качестве части общего пути конкретных экземпляров ресурсов. Избегайте

включения действий в URI с помощью значений QueryString.

 Определитесь с тем, должны ли поддерживаться несколько реализаций для разных

ресурсов. Например, решите, должен ли ресурс поддерживать формат XML, Atom или

JavaScript Object Notation (JSON), и сделайте его частью запроса к ресурсу. Ресурс

может предоставляться и как (например) http://www.contoso.com/example.atom, и

как http://www.contoso.com/example.json. Не используйте значения QueryString для

определения действий с URI. Все действия должны основываться на HTTP-операции,

выполняемой по отношению к URI.

 Не злоупотребляйте операцией POST. Хорошей практикой является использование

конкретных HTTP-операций, таких как PUT или DELETE, это обеспечит создание

дизайна на основе ресурсов и использование унифицированного интерфейса.

 Применение протокола приложений HTTP позволит использовать общую

инфраструктуру Веб (кэширование, аутентификацию, общие типы представления

данных и т.д.).

 Обеспечьте безопасность запросов GET в том смысле, чтобы они всегда возвращали

один и тот же результат. Сделайте запросы PUT и DELETE идемпотентными, т.е.

повторяющиеся идентичные запросы должны приводить к тому же эффекту, что и

одиночный запрос.

Слой сервисов

Слой сервисов включает компоненты, определяющие и реализующие сервисы для

приложения. В частности, этот слой содержит интерфейс сервиса (составленный из

контрактов), реализацию сервиса и трансляторы, которые преобразуют внутренние бизнес-

сущности в и из внешних контрактов данных. При проектировании слоя сервисов

руководствуйтесь следующими рекомендациями:

 Не реализуйте бизнес-правила в слое сервисов. Слой сервисов должен заниматься

только управлением запросами к сервису и преобразованием контрактов данных в

сущности для использования бизнес-слоем.

 Доступ к слою сервисов должен определяться политиками. Политики обеспечивают

потребителям сервиса способ описания требований к подключению и безопасности, а

также других деталей, связанных с взаимодействием с сервисом.

 Размещайте основные компоненты слоя сервисов в отдельных сборках. Например,

интерфейс, реализация, контракты данных, контракты сервисов, контракты сбоев и

трансляторы – для каждого из них должна быть создана собственная сборка.

 Взаимодействие с бизнес-слоем должно осуществляться только через общеизвестный

открытый интерфейс. Слой сервисов никогда не должен обращаться к компонентам

базовой бизнес-логики.

 Слой сервисов должен знать, какие бизнес-сущности используются бизнес-слоем.

Обычно это обеспечивается созданием отдельной сборки, в которую помещаются все

бизнес-сущности, совместно используемые слоем сервисов и бизнес-слоем.

SOAP

SOAP – протокол обмена сообщениями, при использовании которого сообщение формируется

как XML-конверт, содержащий заголовок и тело. В заголовке могут размещаться сведения,

внешние по отношению к осуществляемой сервисом операции. Например, заголовок может

включать данные, касающиеся безопасности, транзакции или маршрутизации. Тело содержит

контракты, представленные в форме XML-схем, которые определяют сервис и действия,

которые он может осуществлять. По сравнению с REST, SOAP обеспечивает большую гибкость в

выборе протоколов, позволяя использовать более высокопроизводительные протоколы, такие

как TCP. SOAP поддерживает стандарты WS-*, включая безопасность, транзакции и

надежность. Безопасность и надежность сообщения гарантирует, что сообщения не только

достигнут точки назначения, но также что они не будут прочитаны или изменены в ходе

передачи. Транзакции обеспечивают возможность группировки операций и отката в случае

сбоя.

SOAP полезен при взаимодействии типа RPC между сервисами или отдельными слоями

приложения. Он исключителен в обеспечении возможности взаимодействия между новыми и

устаревшими системами во внутренней сети. Слой сервисов может быть размещен поверх

старой системы, делая возможным взаимодействие с системой через API без необходимости

ее переработки для предоставления доступа на базе модели REST-ресурсов. SOAP также

пригодится в случаях, когда данные активно передаются одной или более системам, которые

могут часто менять протоколы связи. Он также может использоваться, если требуется

непрозрачно инкапсулировать данные или объекты и затем сохранять или передавать их

другой системе.

Если хотите обеспечить масштабируемость приложения, применяя Веб-фермы или

балансировку нагрузки, избегайте сохранения состояния сеансов на сервере. Сохранение

сеансов на сервере означает, что данный конкретный сервер должен обслуживать клиента в

течение всего сеанса или, в случае балансировки нагрузки, должен передавать данные сеанса

другому серверу. Передача состояния сеанса между серверами намного усложняет

реализацию сценариев обработки отказов и масштабирования.

При проектировании SOAP-сообщений руководствуйтесь следующими рекомендациями:

 В SOAP-конверте SOAP-заголовок является необязательным элементом, тогда как

наличие SOAP-тела обязательно. В любых схемах сообщений избегайте

использования составных типов.

 Используйте для ошибок SOAP-ошибки, не полагайтесь на стандартный механизм

обработки ошибок. При возвращении данных ошибки SOAP-ошибка должна быть

единственным дочерним элементом SOAP-тела.

 Чтобы обеспечить обработку блока SOAP-заголовка, задайте атрибуту

mustUnderstand (должен интерпретироваться) блока значение «true» или «1».

Ошибки, возникающие при обработке SOAP-заголовка, должны возвращаться как

SOAP-ошибка в элементе SOAP-заголовка.

 Изучите и используйте стандарты WS-*. Эти стандарты обеспечивают единые правила

и методы решения проблем, обычно возникающих в архитектуре, использующей

обмен сообщениями.

Валидация

Эффективная стратегия валидации ввода и данных является критически важной для

обеспечения безопасности приложения. Для него обязательно должны быть определены

правила валидации данных, поступающих от потребителей сервиса. При проектировании

стратегии валидации руководствуйтесь следующими рекомендациями:

 Проверяйте все данные, поступающие в интерфейс сервиса, включая связанные с

сообщением поля данных, и возвращайте информативные сообщения об ошибке в

случае сбоя валидации. Для проверки входящих сообщений используйте XML-схемы.

 Проверяйте все вводимые данные на наличие опасного или злонамеренного

содержимого и учитывайте то, как предполагается использовать данные. Например,

если данные будут использоваться для запросов к базе данных, необходимо

обеспечить защиту базы данных от атак внедрением SQL-кода. Это можно

реализовать путем применения для доступа к базе данных совместно используемых

процедур или параметризованных запросов.

 Выработайте стратегии применения подписей, шифрования и кодирования.

 Определитесь с границами доверия между слоями и где бы то ни было, чтобы

обеспечить валидацию данных при любом пересечении этих границ. Однако если

валидации, выполняемой в других слоях достаточно, чтобы считать данные

пользующимися доверием, повторной проверки таких данных не требуется.

Более подробно методики валидации рассматриваются в главе 17, «Сквозная

функциональность».

Вопросы выбора технологий

При проектировании сервиса примите во внимание следующие вопросы, касающиеся выбора

технологий:

 Для простоты используйте ASMX, но только если доступен Веб-сервер, выполняющий

IIS.

 Используйте WCF-сервисы, если необходимы дополнительные возможности, такие

как надежные сеансы и транзакции, трассировка действий, протоколирование

сообщений, счетчики производительности и поддержка множества транспортных

протоколов.

 Если при использовании Веб-сервисов ASP.NET требуется обеспечить безопасность на

уровне сообщений и передачу двоичных данных, используйте Web Service Extensions

(WSE).

 Если решено использовать WCF, продумайте следующее:

◦ Если требуется обеспечить возможность взаимодействия с не-WCF или не-

Windows клиентами, используйте HTTP-транспорт, основанный на спецификациях

SOAP.

◦ Если требуется поддерживать клиентов в рамках внутренней сети, используйте

протокол TCP и бинарное кодирование сообщений с безопасностью на

транспортном уровне и аутентификацией Windows.

◦ Для поддержки WCF-клиентов на том же компьютере используйте протокол

именованных каналов и бинарное кодирование сообщений.

◦ Используйте контракты с явной, а не неявной оболочкой сообщений. Это

позволит передавать контракты сообщений на вход и выход операций,

следствием чего станет возможность расширять контракты данных, включенные

в контракт сообщения, без влияния на контракт сервиса.

Вопросы развертывания

Для проектирования сервисных приложений, как правило, используется многослойный

подход, при котором слой интерфейса сервиса, бизнес-слой и слой доступа к данным

отделены друг от друга. Для сервисного приложения может применяться распределенное

развертывание абсолютно так же, как для любого другого типа приложения. Сервисы могут

развертываться на клиенте, на одном сервере, на множестве серверов предприятия. Однако

при развертывании сервисного приложения необходимо не забывать о вопросах

производительности и безопасности, как в любом распределенном сценарии, и учитывать все

ограничения, налагаемые средой производственной эксплуатации. При развертывании

сервисного приложения руководствуйтесь следующими рекомендациями:

 По возможности размещайте слой сервисов на одном уровне с бизнес-слоем, это

обеспечит лучшую производительность приложения.

 Если сервис физически располагается в одном слое с потребителем сервиса,

применяйте для связи именованные каналы или совместно используемую память.

 Если доступ к сервису осуществляется только приложениями локальной сети,

используйте протокол связи TCP.

 Конфигурируйте хост сервиса для использования безопасности на транспортном

уровне, только если потребители имеют прямой доступ к сервису и запросы не

проходят через посредников.

 Включайте трассировку и компиляцию в режиме отладки для всех сервисов только на

время разработки и тестирования.

Более подробно шаблоны и сценарии развертывания рассматриваются в главе 19,

«Физические уровни и развертывание».

Шаблоны проектирования

Основные шаблоны проектирования организованы по категориям, таким как Сетевое

взаимодействие, Непротиворечивость данных, Структура сообщения, Конечная точка

сообщения, Защита сообщений, Преобразование сообщений, REST, Интерфейс сервиса и SOAP,

и представлены в следующей таблице. Рассмотрите возможности применения этих шаблонов

при принятии проектных решений для каждой из категорий.

Категория

Шаблоны

Сетевое

взаимодействие

Duplex. Двунаправленный обмен сообщениями, при котором и сервис, и

клиент отправляют сообщения друг другу независимо и без учета того,

какой шаблон используется, One-Way (Однонаправленный) или Request-

Reply (Запрос-ответ)

Fire and Forget. Однонаправленный обмен сообщениями, используемый в

случаях, когда нет необходимости ожидать ответа.

Reliable Sessions. Надежная передача сообщений из конца в конец между