Текст книги "Основы проектирования корпоративных систем"

Взаимодействие между пользователем и сервером осуществляется посредством сеансов связи Session, и существует атрибут Enable Session, который связан с веб-методом и осуществляет включение или выключение поддержки состояния сеанса. Как уже было упомянуто, широко используется технология кэширования, когда тот или иной метод в определенные промежутки времени осуществляет запись ответов метода на запросы для последующего их использования.

При создании веб-сервиса существует достаточно общий и достаточно широкий класс, который так и называется – Web Service, на его основе можно создавать собственные веб-сервисы. Он находится в пространстве имен System.Web.Services. Public Class Service мы создали как раз на основе этого класса System.Web.Services.Web Service, а класс Web Service создали как дочерний на основе этого системного класса, он обладает всеми свойствами своего родителя и реализует все его методы, поскольку речь идет о традиционном объектно-ориентированном подходе. Кроме того, поскольку можно не только использовать существующие атрибуты и методы класса, но и создавать новые, расширять его, мы можем доработать, развить код этого класса, чтобы сделать на его основе свой. Подобно тому, как мы это сделали в примере, когда расширили код созданием дополнительного метода CalculateRoot, который вычислял квадратный корень из числа с плавающей точкой двойной точности, которая в результате и публиковалась на клиенте в веб-браузере.

Мы перечислили целый ряд атрибутов веб-методов. Все эти характеристики доступны из класса Web Service, и мы можем организовать непосредственный доступ к таким параметрам класса Web Service, как сессия, контекст, пользователь, сервер, приложение и т. д. Все они имеются в перечне атрибутов этого класса, управляются его методами, доступны, их описание можно найти в описании этого класса, это свойства Application, Context, User, Server и т. д. И если мы осуществляем наследование от этого класса, т. е. создаем собственные классы на основе данного, мы можем применить технологию. NET Remoting, т. е. использовать не только стандартные средства, связанные с веб-сервисом, но и Remoting для организации удаленного взаимодействия компонентов приложения.

Ранее указывалось, что технология Remoting имеет достаточно развитую библиотеку классов, которая позволяет организовать сессии такого рода взаимодействия. Уже упоминалось слово Disco – это такая странная аббревиатура, которая, к сожалению, явной расшифровки не имеет. Она происходит от слова Discovery – обнаружение, поиск. Это механизм на основе файлов, который служит для обнаружения и поиска локальных веб-сервисов. Кроме того, используются специальный язык WSDL и специальная служба UDDI – Universal Description Discovery and Integration, которая применяется для глобального поиска веб-сервисов. Именно благодаря этой службе становится возможным отыскать веб-сервисы, опубликованные на различных серверах, т. е. компьютерах, расположенных в Интернете. Эта задача на порядок проще, и взаимодействие существенно конструктивнее, чем то, что было сделано в предварительной версии Windows, которая появилась в сети Интернет. Для описания веб-сервисов используется язык WSDL. По сути, это подмножество языка XML, т. е. все, что пишется на WSDL, укладывается в XML-стандарт, но здесь есть специальные теги, подтеги WSDL, которые начинаются со слова WSDL. Здесь описываются type, scheme, element и т. д. То есть речь идет о тех объектах, тех атрибутах объектов и методах, которые используются для описания веб-сервисов. Кроме того, описаны сообщения – Message Name, которыми обмениваются объекты при взаимодействии в рамках веб-сервиса. Здесь используется традиционный протокол, предназначенный для обмена данными по сервисно-ориентированной архитектуре, и язык WSDL.

На самом деле достаточно полезно самостоятельно ознакомиться с описанием веб-сервиса, для того чтобы понять, какое значительное количество кода в нем содержится изначально, который мы не писали, но который автоматически наследуется из стандартного класса Web Service, и, конечно, для того, чтобы понять, какова структура веб-сервиса, какие поля и методы используются, как организуется взаимодействие: как организуются сессии, обмен сообщениями и т. д. Многое можно понять и почерпнуть для себя просто из этого описания, которое на самом деле представляет собой достаточно полное описание всей функциональности и всех атрибутов веб-сервиса. С другой стороны, это описание на достаточно универсальном языке, пусть и несколько громоздком в данном случае, по сути, это XML. Здесь нет в чистом виде C#, а есть основные параметры конфигурации этого веб-сервиса: какие атрибуты ему потребуются. Скажем, у нас есть элемент, который называется Value, имеет тип Double и связан с результатом, который выдает метод CalculateRoot. Выдает он его через объект, называемый CalculateRootResponse. Достаточно много можно почерпнуть из этого описания, если внимательно его просмотреть.

На рис. 11.1 представлена относительно небольшая часть этого описания. Итак, язык WSDL – это не что иное, как просто диалект XML, вариант или подмножество языка XML. Если мы будем стандартным средством разбора просматривать этот текст как XML, мы поймем, что это на самом деле XML. Но сюда включены специфические теги, которые позволяют описывать веб-сервисы. А веб-сервис – это не что иное, как класс, который наследует от стандартного класса Web Service свои свойства и имеет определенные атрибуты и методы. Возвращаясь к рисунку с примером веб-сервиса и его описанием на языке XML, можно заключить, что здесь имеется достаточно глубокая вложенность. То есть это описание имеет не один, а несколько уровней абстракции – имеется XML-схема, которая содержит элементы, скажем, атрибуты и методы. Приблизительно в таком виде выдержано описание веб-сервиса. Следовательно, речь идет об описании класса с достаточно большим уровнем вложенности по атрибутам и методам.

Кроме того, WSDL описывает веб-сервис как модуль, т. е. как некоторую замкнутую, самодостаточную единицу кода, который решает узкую специализированную задачу. В данном случае решается единственная задача – подсчет квадратного корня от того числа, которое будет передано пользователем через Internet Explorer, через веб-интерфейс, и возврат значения в том же интерфейсе. Описание WSDL включается между тегами базового элемента, который называется Definitions и имеет ряд разделов. Эти разделы описывают не только структуру веб-сервиса, но и его функции, не только в смысле его прямого назначения и тех расчетов, которые он осуществляет в данном случае, но и, конечно, в смысле интерфейса, взаимодействия с пользователем. Здесь есть раздел Messages – это сообщения, на основе которых будет строиться обмен с сервером, порты, виды портов, сервисы, которые он задействует, определенного рода Boundings, т. е. связи при осуществлении взаимодействия. Об это речь пойдет более подробно при рассмотрении технологии WCF. Здесь просто отметим, что Bounding – это достаточно важная составляющая. Types and Operations – это, по сути, атрибуты и методы, с которыми имеет дело наш веб-сервис. Нет смысла детализировать каждый из этих разделов, каждый может сделать это самостоятельно, используя XML-представление. Оно, с одной стороны, достаточно большое, с другой – вполне наглядное. Веб-сервисы взаимодействуют между собой на основе протокола SOAP. На самом деле это протокол, который функционирует поверх HTTP. Этот протокол достаточно общего вида, т. е. он никак не связан с Microsoft, с веб-сервисами от Microsoft, по сути, это международный стандарт, который существует для построения веб-сервисов или, лучше сказать, сервисов на основе сервисно-ориентированной архитектуры. Во многом его свойства унаследованы от удаленного вызова процедур. С точки зрения клиента, не существует различия между локальным описанием процедуры, т. е. описанием процедуры, которая будет выполнена локально, и описанием процедуры, которая будет выполнена где-то на удаленном сервере. Примерно таким же образом можно заключить, что нет разницы между описанием сервиса, который будет выполнен локально, так как только в URI разделе фигурирует Localhost. Только поэтому можно заметить, что веб-сервис будет выполнен на том же самом компьютере, с которого и осуществляется вызов. URI – универсальный идентификатор ресурса в Интернете, который, как и любой интернет-адрес, может физически описывать компьютер, находящийся где угодно в Интернете. Таким образом, вызов фактически инкапсулируется внутри самого сервиса. И, что немаловажно, взаимодействие осуществляется по общему протоколу, что позволяет в принципе связывать веб-сервисы, как созданные на основе продуктов Microsoft, так и другие. То есть позволяет строить шлюзы между различными веб-сервисами и вообще различными корпоративными системами. Это очень важно, поскольку корпоративные системы изначально являются гетерогенными. Такая ориентация на открытый протокол позволяет нам реализовывать разветвленные распределенные системы достаточно большого объема и их взаимодействие, независимо или в незначительной степени зависимо от тех технологий, на которых они построены. По сути, так же как в большом количестве других протоколов взаимодействия, речь идет об обмене сообщениями в рамках сессии между клиентом и сервером при таком взаимодействии. Это отчасти похоже и на RPC, скажем, на взаимодействие в связи с подходом CORBA, который был описан ранее, отчасти на COM-модель. По сути, у нас есть некоторый протокол обмена сообщениями, когда каждое сообщение включает в себя заголовок сообщения, некоторое тело, в котором, собственно, говорится о том, что же нужно выполнить, и конверт. Протокол SOAP основан на XML-технологии. То есть он не имеет ничего общего с Microsoft и с технологиями от Microsoft. Он точно так же используется и IBM, и другими. Это открытый протокол, международный стандарт, описание процедур удаленного вызова, описание сообщений в нем реализовано на стандартном XML. При этом среда. NET позволяет настраивать формат сообщений, которые отправляются при помощи веб-метода. Здесь используется протокол SAOP и целый ряд атрибутов, которые являются атрибутами класса Web Service. В частности, имеет смысл отметить пару атрибутов, которые называются SOAP Method Attribute и SOAP RPC Method Attribute. То есть взаимодействие по протоколу SOAP может осуществляться разными способами, в том числе и с явным использованием технологии RPC.

Теперь чуть более подробно о структуре заголовков SOAP, о структуре сообщений в этом протоколе для обмена данными. Существует атрибут SOAP Header Attribute, который как раз и призван осуществлять настройку заголовков. И здесь есть стандартный класс, который называется SOAPHeader и расположен в иерархии пространства имен следующим образом: System.Web.Services, т. е. находится внутри пространства имен веб-сервисов, дальше существует пространство имен Protocols, где есть ряд протоколов, в том числе и SOAPHeader. При этом в описании веб-сервиса для этого атрибута указывается имя переменной класса заголовка. После создания Public Class Service1, который является классом System. Webservices.Webservice, т. е. веб-сервисом, мы создаем некий заголовок Public, имеющий идентфикатор m_full и тип Header1. Затем мы его связываем с классом SOAPHeader и производим дальнейшее преобразование уже с осуществленной привязкой к тому типу заголовка, который мы задали. У протокола SOAP имеется достаточно большое количество расширений, которые мы можем использовать в рамках технологии Web Service от Microsoft для того, чтобы осуществлять обмен данными внутри пакетов в рамках сессий по взаимодействию между клиентом и сервером посредством сообщений. При этом можно осуществлять настройку и обработку этих данных достаточно гибким образом, на основе широких возможностей. Для этого существует класс SOAPExtension, и на его основе можно создать свой класс и использовать атрибут SOAP Extension Attribute для создания собственных расширений и регулирования взаимодействия между компонентами веб-сервиса в рамках этих расширений.

Ранее уже были рассмотрены Proxy и Stub. Proxy является инкапсуляцией сервера веб-сервиса в приложении. При этом Proxy в данном случае объявляется объектом класса, который создается в рамках стандартной библиотеки классов Microsoft.NET Framework и использует наше описание веб-сервиса на языке WSDL. При этом методы класса, который создается и инкапсулирует логику веб-сервиса, соответствуют методам веб-сервиса. Генерация этих классов уже автоматически предполагается в Microsoft.NET Visual Studio. Можно использовать и специальную утилиту, специальное приложение, которое называется WSDL.exe и может осуществлять генерацию такого рода классов, генерацию Proxy веб-сервиса. Интересно, что веб-сервисы могут осуществлять как синхронную, так и асинхронную обработку данных посредством вызова методов. При этом асинхронные методы веб-сервиса отмечаются префиксами begin и end. Каждый раз мы помечаем в квадратных скобках имя метода Method Name, что служит сигналом окончания выхода из процедуры, окончанием вызова метода веб-сервиса. Реализуется специальный интерфейс, который называется IAsyncResult, также можно подписаться на уведомление о завершении метода путем передачи делегата или указателя на событие. Похожего рода обработку информации мы обсуждали во время описания технологии Remoting, возможен вызов метода в асинхронном режиме по похожим схемам.

Последний аспект, который хотелось рассмотреть в связи с веб-сервисами, – это безопасность. Следует напомнить, что достаточно безопасным подходом, который довольно часто, в том числе и в последнее время, используется для производства распределенных приложений на основе технологии. NET, является Remoting. Нужно сказать, что ряд методов может быть использован и в стандартных веб-сервисах, которые работают на основе открытого протокола SOAP, взаимодействуют с клиентом по протоколу HTTP и используются широко в. NET Framework. Наверное, следует разделить эти методы, прежде всего на внутрикорпоративные, т. е. те сети, которые будут использованы для доступных лиц внутри корпорации и, естественно, распределенных приложений, и Интернет – открытую среду. В интранет реализуются технологии межсетевых экранов, firewalls, технологии, связанные с ограничением безопасности на основе протокола IP и IP-конфигурации во внутренних сетях. Создаются и используются технологии на основе VPN – виртуальных частных сетей, также аутентификация на основе протокола взаимодействия SP.net и специализированное расширение, связанное с безопасностью на основе протокола HTTP – это протокол HTTPS и другие варианты. В интернет-системах можно использовать цифровые подписи, применяемые в связи с протоколом SOAP, а также аутентификацию, основанную на использовании элементов конкретных прикладных систем.

На этом закончим обсуждение веб-сервисов. Это достаточно общий подход, который позволяет объединить возможности, которые реализованы Microsoft в платформе. NET, и распространить их на решения более общего вида, на гетерогенные системы, которые функционируют в существенно более гетерогенных средах и объединяют решения не только Microsoft, но и других производителей, поскольку речь идет о взаимодействии на основе протокола SOA и протокола HTTP, которые являются открытыми, и на основе сообщений, которые кодируются или задаются внутри при помощи языка WSDL, который на самом деле есть диалект XML.

Глава 12
Разработка корпоративной сервисно-ориентированной архитектуры по технологии WCF

Нужно отметить, что существуют и другие подходы к построению распределенных приложений. Ранее был рассмотрен подход, связанный с технологией Remoting, он может использоваться также как расширение веб-сервисов. Сейчас будет рассмотрен еще один подход, который называется Windows Communication Foundations (WCF) и является более открытым и более современным, чем Remoting. Он также предназначен для создания и использования распределенных приложений, т. е. продолжает и развивает концепцию программного обеспечения как сервисов. Рассмотрим особенности общего подхода сервисно-ориентированной архитектуры, которая независима от Microsoft или какого-то другого производителя, является международным стандартом, и реализации этой архитектуры от Microsoft. Это как раз SOAP версия Microsoft. Важными понятиями являются контракты, каналы, связывания. Далее эти элементы и их роль в технологии WCF будут рассмотрены более подробно.

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

Рассмотрим достаточно простой, но важный пример реализации сервиса, по сути, тоже веб-сервиса, на основе технологии WCF. Итак, что такое сервисно-ориентированная архитектура, SOA? Речь идет о том, что это открытый протокол или открытая среда взаимодействия приложений, которая архитектурно основана на использовании сервисов, т. е. реализует концепцию программного обеспечения как сервиса. Естественно, приложения при этом представляют собой распределенные компоненты. Сервисно-ориентированная архитектура регламентирует протоколы и методы, т. е. способы и функции, по которым осуществляется взаимодействие. В концепцию сервисно-ориентированной архитектуры укладываются и веб-сервисы, и технология Remoting, и, конечно же, технология WCF, о которой пойдет речь позднее, и ряд других технологий. Очень важны идеология и подход, связанный с нейтральностью сервисов. То есть при реализации веб-сервисов они остаются независимыми друг от друга и взаимодействуют в независимом режиме. Кроме того, сервисы являются строительными блоками бизнес-процессов, на основе которых осуществляется взаимодействие корпоративных приложений. Каждый такой блок представляет собой либо бизнес-процесс в целом, либо часть этого бизнес-процесса.

Взаимодействие в рамках сервисно-ориентированной архитектуры основано на обмене сообщениями, и эта важная характеристика во многом отличает сервисно-ориентированную архитектуру от других подобных архитектур. Протоколы и технологии взаимодействия являются открытыми: SOAP, XML и т. д. По сути, технология WCF является вариантом реализации Microsoft общей стратегии SOA – сервисно-ориентированной архитектуры, которая была разработана в том числе и корпорацией IBM. Как и другие подходы распределенного взаимодействия на платформе. NET, этот подход связан с использованием библиотеки классов. В данном случае речь пойдет о. NET Framework 3.0 и WCF. Этот подход был разработан, чтобы решить ряд важных задач, в том числе таких, как унификация существующих технологий удаленного взаимодействия приложений, сервисно-ориентированная разработка приложений, т. е. разработка приложений, реализующих концепцию программного обеспечения как сервис, и, что очень важно, кросс-платформенное взаимодействие. То есть подход WCF дает возможность взаимодействия различных платформ. При этом устраняется целый ряд препятствий между корпоративными стандартами от Microsoft, IBM, Sun и других компаний, существует организация WSI Web Service Interability, которая реализует унификацию стандартов и спецификаций взаимодействия приложений, созданных в том числе этими разработчиками. Реализация этих стандартов делает возможным сервисно-ориентированное взаимодействие, в том числе и на основе технологий WCF. Набор стандартов не является монолитным, он реализован таким образом, чтобы давать возможность разработчикам его настраивать, развивать и осуществлять реализацию приложений в достаточно гибком режиме на этой основе. Кроссплатформенное взаимодействие основано на открытых протоколах и позволяет объединить решения от перечисленных производителей на основе целого ряда подходов, связанных с веб-сервисами от Microsoft, NET Remoting, службой распределенных транзакций Enterprise Services и др.

Рассмотрим обобщенную архитектуру WCF. Важными понятиями здесь являются контракты, среда исполнения сервисов, сообщения, хостинг. Контракты определяют целый ряд аспектов взаимодействия между сервисами. При этом существует несколько видов контрактов. Скажем, DataContract, ServiceContract и ряд других. DataContract описывает параметры взаимодействия между сообщениями. MessageContract задает части сообщений в стандартном протоколе SOAP, посредством которого взаимодействуют приложения или их компоненты. ServiceConctract определяет сигнатуру методов сервиса, Policy Bounding Contract – политику безопасности взаимодействия тех протоколов, которые будут использоваться в качестве транспортных, и ряд других аспектов. Среда исполнения определяет поведение сервисов и их обработку в то время, когда осуществляется выполнение кода этих сервисов: в каком режиме осуществляется обработка ошибок, как работает инспекция сообщений, как реализована фильтрация сообщений, как происходит диспетчеризация, т. е., по сути, управление сообщениями, как задаются метаданные, как осуществляется представление метаданных, какое количество экземпляров характеризует каждый сервис. Сообщения, слой сообщений определяет возможные форматы и шаблоны обмена сообщениями в общеархитектурной схеме. Наконец, активация и хостинг определяют последовательность запуска сервисов и контекст протоколов их взаимодействия.

Следующим важным понятием является понятие контракта. Прежде чем мы рассмотрим понятие контракта, представим общую схему, которая описывает модель взаимодействия компонентов приложения в рамках подхода WCF. Здесь следует выделить уровень клиента и уровень сервера. Как клиент, так и сервер взаимодействуют посредством контракта и реализуют определенные сценарии поведения, которые активируются в зависимости от тех особенностей контрактов, которые определяют их взаимодействие. По сути, речь идет о том или ином связывании, т. е. конкретизации особенностей протокола или особенностей вызова этих сценариев. Обмен данными между клиентом и сервером происходит на уровне сообщений. Здесь принципиальным является выбор канала взаимодействия, осуществляемого посредством адресов, между которыми осуществляется обмен сообщениями. Контракт описывает тип сообщений, которыми обмениваются участники взаимодействия, т. е. клиенты и серверы. Кроме того, контракт описывает формат сообщений и другие спецификации.

В WCF реализуются три вида контрактов: контракт сервиса (Service Contract), контракт данных (Data Conctract), контракт сообщения (Message Contract). Контракты сервисов используются для описания функциональности, которую поставляет сервис. Вместе с операционными контрактами они определяют те методы из. NET Framework, которые описывают операции, осуществляемые сервисами, и те конкретные порты, посредством которых осуществляется взаимодействие. Порты описываются на языке WSDL. Здесь мы видим, что технология WCF тесно связана с технологией веб-сервисов. Она использует тот же самый язык описания. Контракты данных описывают структуры данных, которые служат для взаимодействия сервисов. В частности, определяются типы CLR, среды выполнения Common Language Runtime и XSD, т. е. полностью описываются сериализация и десериализация – преобразование данных при передаче от клиента к серверу. Третьим типом контрактов, на основе которых осуществляется взаимодействие в рамках WCF, являются контракты сообщений. Контракты сообщений описывают, каким образом типы среды взаимодействия CLR будут преобразованы на уровне данных в сообщения протокола SOAP. При этом существует возможность гибких настроек этих сообщений в SOAP, как заголовков, так и тел сообщений. Более подробно сервисные контракты определяют интерфейсы конечных точек веб-сервиса. При этом для указания контрактов используются атрибуты Service Contract и Operation Contract, которые применяются соответственно для классов и интерфейсов и для методов веб-сервисов. Данные контракты используются в технологии WCF как при проектировании, так и при выполнении веб-сервисов. При этом на стадии проектирования определяются те классы, которые при описании веб-сервиса должны быть описаны на языке WSDL как конечные точки сервисов, указываются операции, которые будут задействованы в этих элементах.

На стадии выполнения осуществляются поиск и выполнение методов на сервере, которые связаны с активацией тех или иных сервисов. Если речь идет о Service Contract и Operation Contract, то эти атрибуты задают порядок взаимодействия. В том числе возможно как однонаправленное взаимодействие, так и дуплексное. При однонаправленном взаимодействии, которое кодируется свойствам и атрибута Is One Way, клиент получает только подтверждение взаимодействия с веб-сервисом. При дуплексном взаимодействии устанавливается полноценный двунаправленный обмен сообщениями. При этом сообщения могут посылаться как от клиента серверу, так и от сервера клиенту. Сообщения для этого снабжаются соответствующими атрибутами, такими как адрес, способ связывания и контракт: Address, Binding and Contract. В WCF это основа взаимодействия, которая кодируется аббревиатурой ABC: Address, Binding, Contract. Это является важным порядком, по сути, описанием порядка взаимодействия. При таком взаимодействии используется один и тот же транспортный протокол, при необходимости создается новый канал. При этом в дуплексных контрактах используются контракты как клиента, так и сервера.

Обсудив контракты сервисов, переходим к рассмотрению контрактов данных. Данные сервиса представлены типами CLR, с другой стороны, это внутренние типы среды выполнения Common Language Runtime, извне они поступают как описание веб-сервиса на языке WSDL. Таким образом, контракты данных являются связующим звеном между внешним WSDL и внутренним CLR представлением. Для определения контрактов данных используются атрибуты Data Contract и Data Member. При этом Data Contract используется как атрибут класса, а атрибут Data Member используется как атрибут члена этого класса, семейства или как атрибут поля. Важно отметить, что оба эти атрибута – и Data Contract, и Data Member – используются как при проектировании класса, веб-сервиса, так и при его реализации. Контракт данных обеспечивает сериализацию данных, при этом используется атрибут Data Contract Serializer. Контракты сообщений – это третий тип контрактов, определяют собственно представление сообщений в формате SOAP, т. е. то, каким образом внутренние типы CLR будут представлены в формате взаимодействия. С помощью атрибутов контрактов сообщений – это Message Contract, Message Header, Message Body Member – осуществляется управление разработчиком над представлением данных в формате SOAP. Разработчик при этом получает достаточно мощное средство управления контрактами, представлением этих контрактов. Атрибут Message Contract определяет структуру SOAP сообщения, но не определяет их содержания. То есть он не определяет, скажем, нужно ли сворачивать, архивировать тело сообщения или не нужно. Другие атрибуты используются для настройки заголовка и тела сообщения SOAP. Данный вид контрактов не используется вместе с Data Contract. При этом при использовании с Message Contract необходимо наличие только одного входящего и одного исходящего параметра, поскольку осуществляется прямое преобразование в SOAP.

На рис. 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 и др. Если ни одна из этих стандартных конфигураций не удовлетворяет разработчиков, есть возможность создания собственных конфигураций на основе существующих.