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

Перейдем к более подробному описанию среды хостинга 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 адрес, связывание и контракт. Вот такое небольшое описание кода завершает наш сервис.