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

Взаимодействие между каналами с использованием механизмов связывания имеет достаточно сложную схему, которая логически представлена в форме следующего алгоритма. Прежде всего выявляется наличие необходимости интероперабельности или взаимодействия с другими платформами. Здесь оно представлено ромбом с надписью «Требуется интероперабельность?». При этом в случае позитивного ответа мы перемещаемся вниз, в случае негативного – вправо. Если интероперабельность требуется, то нужно уточнить, какой именно уровень интероперабельности будет использован: общий, на основе 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. При этом на сервере, кроме упомянутых сценариев, реализуются еще два вида специфических для серверной части сценариев. Это выбор операции, т. е. метода, и вызов этой операции. В первом случае рассматривается и анализируется входящее сообщение и происходит определение метода для обработки этого сообщения, того метода, который соответствует этой операции. Во втором случае осуществляется обслуживание этого вызова, т. е. обработка этой операции тем самым методом, который предназначен для нее на сервере.

Рассмотрим некоторые из сервисных сценариев поведения. Заметим, что они определяются соответствующими классами WCF, которые реализованы в. NET. Введем понятие меры параллельности. Это число задач, одновременно выполняемых тем или иным сервисом. То есть таких задач, которые можно понимать как отдельные задачи или отдельные работы. Под временем выполнения задачи будем понимать то время, которое сервис затрачивает на одну задачу. Производительностью будем считать число задач, которые сервис выполняет в единицу времени. Увеличить производительность можно одним из двух способов: либо уменьшить время выполнения, либо увеличить меру параллельности. При этом для задач существуют сценарии поведения, которые называются Instance Context Mode и Concurrency Mode и реализуют соответственно две эти стратегии, увеличивают количество экземпляров сервиса или количество потоков на экземпляр сервиса. Первый класс Instance Context Mode определяет, какое количество экземпляров сервиса будут обслуживать запросы. При этом возможны три режима выполнения: режим Single – единственный экземпляр сервиса для всех запросов, режим Percall – для каждого запроса создается свой отдельный экземпляр сервиса, режим Persession – для каждой сессии создается отдельный экземпляр сервиса. Другой подход связан с числом потоков на экземпляр сервиса и имеет возможные значения: Single, Reentrant, Multiple. Single определяет, что единственный поток имеет доступ к классу сервиса, он может покидать сервисный класс, но обязан вернуться и продолжить операцию. Режим Multiple реализует многопоточный доступ к одному и тому же сервису, а при режиме Reentrant только один поток имеет доступ к классу сервиса. Еще одним важным сценарием поведения является реализованный как класс WCF сценарий Service Meta Data Behaviour, который позволяет публиковать метаданные о сервисе, т. е. все параметры, которые его определяют. Достаточно сказать, что все описание в WSDL-формате может публиковаться этим классом. При этом метаданные предоставляются сервисом посредством конечной точки – Metadata Exchange. То есть существуют специальный формат данных и специальное средство предоставления метаинформации о сервисе.

Как упоминалось ранее, важным средством взаимодействия клиента и сервера при реализации технологии WCF являются транзакции. При этом сценарии поведения на основе этих транзакций могут быть реализованы различными способами. Транзакции бывают двух типов: многошаговые бизнес-процессы и так называемые короткие транзакции, которые, в отличие от первого типа, завершаются достаточно оперативно и затрагивают относительно небольшое количество объектов и связей, зависимостей или ограничений целостности. WCF поддерживает второй вид транзакций, короткие транзакции. Рассмотрим, для чего используется атрибут Operation Behaviour и его свойство Transactionscope Requirement. Это свойство определяет, будет ли операция выполняться в режиме так называемых транзакций, или будет ли транзакция завершаться автоматически (Transaction Scope Complete) при окончании работы метода, или же ее можно будет завершить. В таком случае потребуется поддержка механизма взаимодействия, который реализуется на основе сессий. Важным аспектом взаимодействия между клиентскими и серверными частями приложений по технологии WCF является сериализация и десериализация. Сериализация – это процесс преобразования графа объектов в поток байтов, т. е. в последовательный поток формата XML Info Set. Таким образом, сериализация является эффективным способом сохранения состояния объектов, которое может храниться в базе данных или файле. В WCF состояние объектов хранится исключительно в XML Info Set. Особенность в том, что здесь, в отличие от XML, не задается конкретного формата данных. Используется процесс кодировки, преобразования сообщения WCF в поток байт, во внутреннее представление процесса, и существуют различные виды кодировки, которые доступны в WCF. Всего таких представлений пять. Это двоичный формат, текстовый формат, формат Message Transmission Optimization Mechanism (MTOM), формат, связанный с Java Script, Java Script Object Notation, и формат POX, Plain Old XML, связанный с традиционным XML. При этом выбор кодировки зависит от конкретной ситуации, от конкретных требований ПО по надежности, производительности, интероперабельности, масштабируемости и т. д.

Рассмотрим методы сериализации WCF в сравнении. Произведем сравнение механизмов сериализации, которые реализуются процедурами Data Contract Serializer, Net Data Contract Serializer, XML Serializer и Data Contracts JSON Serializer. Стандартным сериализатором является первый из них, Data Contract Serializer. Он преобразует внутренние типы WCF во внешнее представление XSD, которое является платформенно-независимым. То есть, по сути, не несет связанных с. NET элементов и поэтому может использоваться для взаимодействия со сторонними приложениями, скажем, с приложения, реализованными на основе Java. Для того чтобы этот сериализатор работал с классом, класс необходимо снабдить атрибутом Data Contract, а свойство или поля, которые используются для сериализации, необходимо снабдить атрибутом Data Member. Следующий вид сериализации, Net Data Contract Serializer, близок к первому, но отличается возможностью добавления информации о внутренних типах CLR к тем возможностям, которые имеются у сериализатора по умолчанию. В отличие от первого вида, он используется для. NET приложений и при этом осуществляет взаимодействие между частями этого приложения, причем только одного. NET приложения. Третьим классом, который отвечает за сериализацию, является XML Serializer. Это стандартный сериализатор. NET, который появился еще на уровне Framework 2.0 и сохранился в Framework 3.0. Он позволяет реализовать стандартный механизм сериализации, т. е. работать со стандартными типами. NET, имеет возможность настройки XML-представления, позволяет настраивать выход XML, который генерирует сервис, и работает со стандартными сервисами формата ASP.NET. При этом существуют три основных подхода к использованию данного вида сериализации. Можно использовать стандартную сериализацию, а также атрибуты, связанные с XML: XML Attribute, XML Element. Кроме того, можно использовать интерфейс IXML Serializer, который позволяет организовать взаимодействие с XML-форматом. Еще один важный вид сериализации Data Contract JSON Serializer, который поддерживает стандартную нотацию объектов в формате Java Srcipt.

Важным понятием, характерным для технологии WCF, является понятие host или servicehost. По сути, данное понятие определяет процесс, который несет ответственность за обработку и контекст выполнения веб-сервиса. Это процесс операционной системы, который управляет выполнением сервиса и контекстом, отвечает за старт сервиса, остановку этого сервиса, а также предоставляет важные базовые функции управления сервисом. Хостом сервиса WCF может выступать любой процесс ОС. Такие приложения, как Internet Information Service, Windows Process Activation Service, имеют встроенную поддержку хостинга, т. е. внутреннюю инфраструктуру, которая этот хостинг реализует. Кроме этих подходов можно использовать другой сервис, любой Windows Service, а также любое приложение с пользовательским интерфейсом или консольное приложение для того, чтобы осуществить поддержку хостинга. В зависимости от того, что именно является хостом сервиса, его конфигурация и настройка осуществляются в целом единообразно. Выбор хостинга зависит от требований к приложению, его быстродействию, устойчивости, масштабируемости и т. д. Каждый хост WCF требует реализации трех функциональных элементов: это объект класса ServiceHost, конечная точка и запуск прослушивания сообщений на сервере или процедуры listen.

Перейдем к более подробному описанию среды хостинга Windows (Process) Activation Services или W(P)AS, которая является стандартной средой хостинга (рис. 12.2). Она встроена в новые операционные системы – Windows Vista и серверную ОС Windows Server 2008, поддерживает ряд возможностей, которые раньше были доступны только через Internet Information Service. W(P)AS позволяет размещать сервисы в гибкой среде, которая не требует обязательного использования протокола HTTP. Предположим, что есть однонаправленное взаимодействие с некоторым сервисом и конечный пользователь этого сервиса, который довольно часто находится в отсоединенном от сервиса состоянии. В данном случае в качестве транспортного уровня лучше использовать MSMQ, чем HTTP, который не сохраняет состояния. Или, допустим, у сервиса много клиентов, с которыми он часто обменивается небольшими по размеру сообщениями. В этом протокол HTTP также подходит в меньшей степени, и выгоднее использовать протокол TCP. При этом желательно поддерживать множественность протоколов. Такую возможность дает W(P)AS, эта среда многопротокольная, здесь не требуется обязательное использование протокола обмена HTTP, т. е. осуществляется возможность работы в гибкой среде. Эта возможность поддерживается за счет реализации шаблона Listener Adapter, который абстрагирует слушателей, осуществляющих взаимодействие с процессами, от клиента, от процессов управления.

Рис. 12.2. Схема реализации хостинга в среде W(P)AS

На рис. 12.2, где показана схема взаимодействия процессов различных протоколов с хостом процесса, т. е. с реализацией хостинга на основе технологии W(P)AS, видно, что могут использоваться различные протоколы взаимодействия, и с точки зрения хоста безразлично, каким образом, по какому конкретно протоколу организовано это взаимодействие. Возможно и взаимодействие точка-точка, и взаимодействие по протоколу, который не сохраняет состояние, HTTP, и взаимодействие по TCP-протоколу, и взаимодействие по протоколу, скажем, MSMQ. Рассмотрим небольшой пример веб-сервиса в рамках технологии WCF, который реализует функции калькулятора.

Рассмотренный в предыдущей главе (см. рис. 11.1) пример задействовал всего одну функцию – вычисление квадратного корня. В данном примере будет рассмотрен достаточно простой калькулятор, который осуществляет функции сложения, вычитания, умножения, деления (рис. 12.3). Он заимствован из стандартных примеров кода Microsoft (эти примеры расположены на Micfosoft.Servicemo del. Samples), реализован как интерфейс, который называется ICalculator.

Рис. 12.3. Описание сервиса WCF, реализующего функции калькулятора

На вход каждой операции, которая представляет собой контракт-интерфейс, снабженный атрибутом Service Contract, и в каждой операции мы используем атрибут Operation Contract. Каждая операция представляет собой метод, на вход которого поступают два значения типа Double – число с плавающей точкой двойной точности, выход тоже представляет собой число типа Double. Рассмотрим, каким образом реализуется класс, который выполняет этот контракт. Мы указываем, что это класс общедоступный Calculator Service и использует тот интерфейс, который был ранее определен, определенный нами интерфейсный контракт ICalulator. Контракт реализует соответствующий интерфейс и не требует никаких дополнительных атрибутов. Фактически реализуются те же операции, возвращаются значения суммы, разности, произведения или частного. При этом осуществление вычислений реализуется достаточно наивно, т. е. нет проверки, скажем, на нулевой делитель и других, возможно, важных проверок, которые потребовались бы. Здесь осуществляется просто обращение к стандартным функциям, и будет, видимо, задействовано стандартное исключение CLR, при ошибке, скажем, деления на ноль или другой арифметической ошибке, которая возникнет в случае исключения того или иного рода. Продолжим обсуждение примера – веб-сервиса, который реализует простейший калькулятор. Кроме того, что мы создали описание кода в форме интерфейса и контракта, мы должны реализовать конфигурационный файл, который будет расположен на сервере. Это, естественно, XML-подобное описание, и оно достаточно громоздкое.

В данном случае оно представлено на рис. 12.4. Что характерного в нашем описании сервиса с этой точки зрения можно заметить? Прежде всего, здесь описана конечная точка, через которую ведется взаимодействие. Связывание определено как WSHTTP Binding, т. е. мы используем тип связывания с учетом протокола HTTP. При описании веб-сервиса мы должны определить наше ABC. В рамках выбранной сервисной модели на основе пространства имен System должно быть описано определение, связанное с описанием Calculator Service, который определен ранее, реализует интерфейсный контракт и расположен внутри пространства имен Micfosoft.Servicemodel.Samples. При этом определяется конфигурация поведения Calculator Service Behaviour, а именно какой адрес интерфейса поставляется хостом, где хранится этот интерфейс. Далее указывается необходимый адрес, привязка ABC, которая имеет вид HTTPBinding, и, наконец, интерфейсный контракт, т. е. тот самый интерфейс ICalculator, который у нас описан. Особенности использования связывания типа wsHttpBinding состоят в том, что в качестве протокола взаимодействия используется протокол HTTP, который не сохраняет состояния, и используются стандартные протоколы веб-сервисов WS для организации взаимодействия между клиентом и сервером с точки зрения адресации, безопасности. Сервисы WCF не осуществляют экспорт своих метаданных по умолчанию при такого рода связывании. Для этого сервису необходимо явно указать точку обмена метаданных в виде Metadata Exchange, ее конфигурация явно присутствует в файле конфигурации: явно указаны ABC адрес, связывание и контракт. Вот такое небольшое описание кода завершает наш сервис.

По результатам реализации сервиса осуществляется автоматизированная генерация кода для клиента, которая выполняется при помощи утилиты SWSUtil.exe. Некоторые фрагменты реализации этого кода (рис. 12.5), представляющие собой основные элементы этого кода, выглядят следующим образом: в этом описании присутствуют интерфейсы, которые называются ICalculator и ICalculatorClient. Дано описание класса ICalculatorClient, все, что касается его конечных точек с точки зрения адресов и основных функций, которые он реализует. Функции add, substract, multiply, divide, которые реализованы для этого интерфейса.

Рис. 12.4. Файл конфигурации WCF-сервиса

Заканчивая описание технологий WCF, хочется отметить, что эта технология достаточно зрелая, связана во многом с ядром Indigo, с достаточно поздними реализацией ОС: это прежде всего Windows Vista, Windows Server 2008, и здесь реализуется достаточно открытое по сравнению, скажем, с технологией Remoting, взаимодействие между клиентом и сервером. Как мы видели, существует большое количество возможных протоколов взаимодействия, которые прозрачным образом инкапсулируются в технологии W(P)AS, возможны взаимодействия как по протоколу HTTP, так и по протоколу TCP, MSNQ и т. д. При этом поддерживается взаимодействие не только с приложениями, разработанными на основе технологии. NET, но и на основе целого ряда других технологий. Центральным понятием является понятие хостинга, это реализация процесса, которая отвечает за обработку контекста выполнения сервиса. Принципиально важны процессы преобразования графа объектов в формат XML и обратно, сериализация, десериализация. Существует большое количество сценариев для управления потоками данных как на клиенте, так и на сервере, при этом осуществляется выбор вида данных, которые взаимодействуют, это управление транзакциями, управление безопасностью и т. д. Существует большое количество видов связывания. Для того чтобы осуществить взаимодействие, используется схема ABC, адрес, связывание, контракт. Применяется девять типов связывания, которые зависят от необходимости обеспечить интероперабельное взаимодействие, степень безопасности, вид взаимодействия с учетом используемого протокола, с использованием вида сетевого взаимодействия в его конкретизации: требуется ли связь точка – точка или локальное соединение и т. д. Связь между клиентом и сервером осуществляется на основе каналов, которые представляют собой стек протоколов на основе единого интерфейса ICommunicationObject, каналы при этом делятся на транспортные и протокольные и подразумевают как однонаправленное взаимодействие, так и гибкое взаимодействие по двунаправленной дуплексной схеме. Контракты в WCF имеют троякое представление – для сервисов, для данных и для сообщений и являются важной частью обеспечения взаимодействия между клиентом и сервером по схеме ABC. WCF – это Microsoft-версия реализации стратегии сервисно-ориентированной архитектуры, реализации программного обеспечения как сервиса, она поддерживает все необходимые классы. NET Framework, т. е. большое количество базовых операций и атрибутов по взаимодействию клиента и сервиса, поддерживает технологию Remoting и другие технологии Microsoft, а также дает возможность взаимодействия по открытым протоколам SOAP и HTTP с программным обеспечением других производителей, в том числе на основе стандартизованного языка обмена сообщениями WSDL на основе протокола XML.

Рис. 12.5. Код клиентской части WCF-сервиса