Сергей Зыков - Основы проектирования корпоративных систем

На рис. 12.1 представлен пример контрактов сервиса и контрактов данных. Следующим важным понятием, описывающим взаимодействие между клиентом и сервером, являются каналы обмена данными WCF. Каналы являются средством взаимодействия сообщениями между сервисами и их потребителями, при этом каналы используются как для подготовки сообщений, так и для их доставки. Для подготовки сообщений используются так называемые протокольные каналы, а для доставки – транспортные. В этом смысле существует разделение между каналами. Для транспортных протоколов по технологии WCF используются протоколы HTTP, TCP, WebSphere MQ и др. Также осуществляется взаимодействие в формате точка-точка и так называемые именованные каналы. Существуют и сторонние реализации, при этом используется ряд протоколов, скажем FTP, SMTP, на основе протокола, который используется для доставки почтовых сообщений, UDP и ряд других протоколов, скажем, WebSphere MQ, реализованный для поддержки продуктов корпорации IBM и основанный на передаче сообщений. По сути, речь идет о стеке каналов, т. е. в каналах существует несколько уровней: транспортный и протокольный. Протокольный уровень находится на более высокой позиции в стеке, чем транспортный. Протокольные каналы служат для осуществления транзакций, т. е. взаимодействия между клиентом и сервером посредством элементарных операций, и для шифрования. Таким образом, архитектура WCF дает достаточно высокую степень гибкости при настройке взаимодействия между сервисами и клиентами, которые запрашивают эти сервисы.

Рис. 12.1.Описание контракта сервиса и контракта данных

Для каналов WCF характерны три вида взаимодействия: 1) однонаправленное; 2) дуплексное или полноценное двунаправленное, когда и клиент, и сервер могут посылать друг другу сообщения; 3) взаимодействие по типу запрос – ответ. При рассмотрении контрактов достаточно подробно обсуждались эти виды взаимодействия, в частности однонаправленное и дуплексное. Для реализации этих шаблонов используется ряд интерфейсов, которые упоминались в примерах кода, в том числе такие как ISessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionChannel, IReplaySessionChannel, т. е. по сути интерфейсы реализуют каждое из этих конкретных видов взаимодействия. Кроме того, существует единый базовый интерфейс ICommunicationObject, который поддерживает взаимодействие всех классов объектов, участвующих в канальном взаимодействии. Этот общий интерфейс является неизменным для каналов, а также фабрик каналов и механизмов слушания запросов на сервере и используется для реализации всех механизмов взаимодействия. Таким образом, стек каналов представляет собой многоуровневый стек взаимодействия, включает транспортный и протокольный уровни, и может состоять как из одного канала, так и из нескольких. В этом смысле важным является определение «связанный» или Binding. Нужно сказать, что это понятие весьма важно для объектных систем вообще и в математических формализациях с объектными моделями имеет первостепенное значение, скажем, в теории конечных последовательностей в форме λ-исчисления, имеет реализацию в форме связывания переменной со значением. В данном случае под связыванием понимается заранее сконфигурированный стек каналов взаимодействия по технологии WCF. При этом с помощью связывания подход WCF инкапсулирует различные сценарии взаимодействия. Например, Basic HTTP Binding заранее сконфигурирован для взаимодействия со стандартными веб-сервисами по технологии SMX. WSHTTP Binding – для более сложного взаимодействия Web Service Addressing. Ряд других вариантов взаимодействия на основе связывания образует стек каналов, который использует также специализированные элементы, называемые элементами связывания. Всего в WCF определено и может быть использовано до девяти типов связывания. Это, по сути, предопределенные конфигурации, которые используют протоколы HTTP, TCP и др. Если ни одна из этих стандартных конфигураций не удовлетворяет разработчиков, есть возможность создания собственных конфигураций на основе существующих.

Взаимодействие между каналами с использованием механизмов связывания имеет достаточно сложную схему, которая логически представлена в форме следующего алгоритма. Прежде всего выявляется наличие необходимости интероперабельности или взаимодействия с другими платформами. Здесь оно представлено ромбом с надписью «Требуется интероперабельность?». При этом в случае позитивного ответа мы перемещаемся вниз, в случае негативного – вправо. Если интероперабельность требуется, то нужно уточнить, какой именно уровень интероперабельности будет использован: общий, на основе Basic HTTP Binding или более сложный, с поддержкой дуплексного взаимодействия, тогда используется WS Dual HTTP Binding. Если требуется повышенный уровень безопасности, будет использоваться еще один уровень связанности. Таким образом, все девять типов связывания присутствуют в схеме.

Локальное связывание использует подход NET Named Binding, а также очереди на основе MSNQ, с поддержкой расширений, в том числе на основе сервисно-ориентированных продуктов сторонних производителей. Могут быть также организованы сети по принципу точка-точка, и тогда используются механизмы, связанные с NET TCP Binding. Кроме того, может использоваться подход, связанный с NET Pear TCP Binding. То есть может быть использован целый ряд априори сконфигурированных сценариев взаимодействия в рамках этой технологии. Как упоминалось ранее, могут быть использованы дополнительные сценарии на основе существующих, полученные посредством их развития. Важным средством взаимодействия между клиентом и сервером является так называемый сценарий поведения. По сути, это класс, который реализован в рамках технологии WCF, существует в соответствующем пространстве имен и оказывает влияние на поведение системы во время выполнения приложения.

В WCF существуют следующие виды сценариев использования. Это сервисный сценарий или сценарий сервера. Он работает на уровне сервиса, реализован на сервере, имеет доступ ко всем конечным точкам сервера и влияет на поведение системы во время выполнения. Реализация этого сценария по принципу передачи сообщения от одной точки к другой. Кроме того, существует возможность создания пользовательских сценариев использования. Сценарии использования, которые отвечают за сервисы, поддерживают обработку транзакций, авторизацию пользователя на сервере, создания пользователями объектов и изменения этих объектов, а также аудит действий пользователя. Другим классом сценариев поведения является сценарий конечных точек или NetPoints. Здесь работа осуществляется на уровне конечных точек, реализуется инспекция, т. е. осмотр и обработка сообщений, которые поступают на сервер. Еще один сценарий – это Callback, сценарий обратного вызова, аналог сценария, который реализуется для сервера, сценария сервисного, и функционирует на клиенте в режиме дуплексного, т. е. полноценного, взаимодействия между клиентом и сервером. Следующий вид сценариев – сценарии операционные, они используются на уровне отдельных операций и управляют сериализацией, т. е. преобразованием форматов данных при передаче от клиента серверу, и наоборот, а также потоком транзакций, т. е. элементов взаимодействия между клиентом и сервером. Сценарии взаимодействия конечных точек отвечают за обработку данных до и после того, как они попадаются на обработку конечному методу. При этом на клиенте выделяются следующие три вида сценариев поведения: связанные с инспекцией параметров, сообщений и форматирования сообщений. При инспекции параметров данные исследуются, анализируются и преобразуются до их сериализации в XML-представление. При форматировании сообщений данные исследуются и преобразуются во время конвертации в XML в ходе преобразования. И, наконец, при инспекции сообщений представление данных в формате XML преобразуется при трансляции во внутреннее представление Microsoft.NET. При этом на сервере, кроме упомянутых сценариев, реализуются еще два вида специфических для серверной части сценариев. Это выбор операции, т. е. метода, и вызов этой операции. В первом случае рассматривается и анализируется входящее сообщение и происходит определение метода для обработки этого сообщения, того метода, который соответствует этой операции. Во втором случае осуществляется обслуживание этого вызова, т. е. обработка этой операции тем самым методом, который предназначен для нее на сервере.