В рамках каждого канала можно указать и настроить нестандартные канальные приемники и форматеры. Как было сказано выше, Remoting основана на передаче объектов-сообщений. Используя секции конфигурационных файлов <clientProviders> и <serverProviders>, можно задать цепочку канальных приемников, через которые проходит сообщение, и форматер сериализации сообщения.
Структура секции <serverProviders> на стороне сервера выглядит следующим образом:
<channels>
<channel ref="http" port="1234">
<serverProviders>
<formatter />
<provider />
</serverProviders>
</channel>
</channels>
Свойство <formatter> может присутствовать в одном экземпляре, свойств <provider> допускается несколько. Требуется учесть, что порядок свойств <provider> имеет значение. Подробно об атрибутах, специфичных для канальных приемников, будет рассказано ниже.
Следующие атрибуты являются общими, как для приемника, так и для форматера:
· ref – ссылка на стандартный канальный приемник или форматер ("soap", "binary", "wsdl") или ссылка на канальный приемник или форматер, предварительно описанный в конфигурационном файле;
· type – главный атрибут, если не задан атрибут ref. Содержит точное имя типа канального приемника, с указанием пространства имен и сборки. Для глобальных сборок требуется указывать сильное имя.
В качестве примера использования обсуждаемых атрибутов и секций рассмотрим следующий. Как известно, по умолчанию канал HTTP использует SOAP-форматер для кодирования сообщений. Следующие фрагменты конфигурационного файла настроят канал на использование двоичного форматера.
На стороне сервера требуется записать в конфигурационном файле[18]:
<channels>
<channel ref="http" port="1234">
<serverProviders>
<formatter ref="binary" />
</serverProviders>
</channel>
</channels>
На стороне клиента используется такой фрагмент:
<channels>
<channel ref="http>
<clientProviders>
<formatter ref="binary" />
</clientProviders>
</channel>
</channels>
<service />
Тэг позволяет зарегистрировать и настроить удаленные классы с серверной и клиентской активацией, которые публикует данная сборка как сервер. Секция <service> содержит требуемое количество подсекций <wellknown> и <activated>.
<wellknown>
В этой подсекции на стороне сервера описываются публикуемые удаленные типы с серверной активацией. Тэг поддерживает атрибуты, которые аналогичны параметрам вызова метода RegisterWellKnownServiceType():
· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key;
· mode – индикатор, указывающий вид активации: "Singleton" или "SingleCall";
· objectUri – концевая точка, URI для обращений к объектам удаленного класса. Если используется IIS-хостинг для классов, URI должен оканчиваться на .soap или .rem для корректной обработки. Эти расширения отображаются на инфраструктуру Remoting в метабазе IIS;
Используя следующий файл, сервер позволяет осуществить доступ к объектам класса CustomerManager по URI http://<host>:1234/CustomerManager.soap:
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" port="1234" />
</channels>
<service>
<wellknown mode="Singleton"
type="Server.CustomerManager, Server"
objectUri="CustomerManager.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
<activated>
В подсекции <activated> описываются публикуемые сервером удаленные типы с клиентской активацией. Так как полное имя концевой точки в случае клиентской активации определяется именем приложения сервера, единственный атрибут, который указывается в секции <activated> – это тип публикуемого класса:
· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key.
Следующий пример позволит клиентам создавать объекты класса MyClass по адресу http://<hostname>:1234/
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" port="1234" />
</channels>
<service>
<activated type="MyClass, MyAssembly"/>
</service>
</application>
</system.runtime.remoting>
</configuration>
<client />
На клиентской машине тэг <client> является аналогом тэга <service> на сервере. Структура этих тэгов совпадает:
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown />
<activated />
</client>
</application>
</system.runtime.remoting>
</configuration>
При использовании объектов с клиентской активацией тэг <client> должен при помощи атрибута url указать адрес сервера, содержащего типы, указанные в секции <activated>[19]:
· url – URL сервера. Обязательно указывать, если используются объекты с клиентской активацией;
Секция <wellknown> используется, чтобы зарегистрировать типы с серверной активацией на клиенте и позволяет использовать оператор new для инициализации ссылок на удаленные объекты. Секция <wellknown> на клиентской стороне имеет такие же атрибуты, как и параметры метода Activator.GetObject():
· url – полный URL к классу, зарегистрированному на сервере;
· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key;
Если клиент указал некий тип как удаленный, исполняющая среда изменяет поведение оператора new. CLR отслеживает вызовы new, и в том случае, когда речь идет об удаленном типе, возвращается ссылка на серверный объект, а не создается локальный экземпляр типа. В случае следующего конфигурационного файла для получения удаленной ссылки достаточно написать CustomerManager x = new CustomerManager().
Секция <activated> используется, чтобы указать типы с клиентской активацией на клиенте. Так как URL сервера уже был указан как атрибут секции <client>, то единственный атрибут секции <activated> позволяет специфицировать тип:
· type – информация о типе публикуемого класса в форме "<namespace>.<classname>, <assembly>". Если используется сборка из GAC, требуется указать версию, культуру и public key.
Данные из секции <activated> также используются для переопределения поведения оператора new. При использовании конфигурационного файла, приведенного ниже, для получения удаленной ссылки достаточно написать MyRemote x = new MyRemote().
<configuration>
<system.runtime.remoting>
<application>
<client url="http://localhost:1234">
<activated type="Server.MyRemote, Client" />
</client>
</application>
</system.runtime.remoting>
</configuration>
Клиентское приложение может иметь локальный доступ к библиотеке с удаленными классами (в том случае, если не используется разделение удаленного класса на интерфейс и реализацию). В этом случае следует иметь в виду, что загрузка конфигурационных параметров инфраструктуры Remoting должна быть выполнена до первого вызова конструктора удаленного типа. В противном случае тип будет рассматриваться как локальный и никаких обращений к серверу при работе с объектами производиться не будет.
3.7. Хостинг распределенных приложений
В данном параграфе обсуждаются различные виды размещения (хостинга) серверных компонент распределенных приложений. В качестве примера удаленного класса на протяжении параграфа будет использоваться простой класс BSUIR.Calculator, который скомпилирован в сборку с именем calc.dll.
using System;
namespace BSUIR {
public class Calculator: MarshalByRefObject {
public Calculator() {
log("Calculator constructor");
}
public double Add(double x, double y) {
log("Add " + x + " + " + y);
return x + y;
}
public static void log(string s) {
Console.WriteLine("[{0}]: {1}",
AppDomain.CurrentDomain.FriendlyName, s);
}
}
}
Обратите внимание, что в компоненте не выделен интерфейс. Для предоставления клиенту метаданных компонента будем просто передавать сборку с компонентом клиенту.
Клиент, используемый в примерах, достаточно стандартен:
using System;
using System.Runtime.Remoting;
using BSUIR;
class CalcClient {
public static void Main() {
string filename = "client.exe.config";
RemotingConfiguration.Configure(filename);
Calculator c = new Calculator();
Console.WriteLine(c.Add(3, 4));
}
}
Настройка Remoting на стороне клиента выполняется при помощи файлов конфигурации, которые будут описаны ниже.
В Remoting серверные компоненты распределенных приложений могут использовать хостинг на основе консольных приложений или приложений Windows Forms, хостинг Windows-сервиса или хостинг при помощи веб-сервера Internet Information Server (IIS).
Хостинг на основе консольных приложений или приложений Windows Forms прост в реализации. Однако такой вид хостинга имеет ряд недостатков. В частности, необходим ручной запуск приложения-сервера, затруднено решение проблем аутентификации и логирования.
Рассмотрим хостинг компонент с использованием Windows-сервиса. В .NET Framework пользовательский Windows-сервис – это класс, производный от ServiceProcess.ServiceBase. Обычно в классе требуется переписать виртуальный метод onStart() для выполнения некоторых полезных действий. В следующем листинге приведена «заготовка» пользовательского сервиса:
using System;
using System.ServiceProcess;
namespace WindowsService {
public class DummyService : ServiceBase {
public static string SVC_NAME = "Some dummy service";
public DummyService() {
// в конструкторе установим свойство – имя сервиса
this.ServiceName = SVC_NAME;
}
static void Main() {
//стартуем сервис
ServiceBase.Run(new DummyService());
}
protected override void OnStart(string[] args) {
// полезный код сервиса
}
protected override void OnStop() {
// действия сервиса перед остановкой
}
}
}
Для установки пользовательского сервиса в систему требуется создать специальный класс-инсталлятор. Этот класс будет обрабатываться утилитой установки installutil.exe, которая входит в состав .NET Framework. В следующем листинге показан простой класс-инсталятор, настраивающий сервис на автоматический старт при запуске системы:
Два файла – файл с кодом сервиса и файл с классом-инсталлятором – требуется скомпилировать в одну сборку (например, CustomWinServ.exe). Для установки сервиса выполняется следующая команда:
installutil CustomWinServ.exe
В случае успешной установки сервис ведет себя как любой стандартный сервис, он допускает управление (старт-стоп) при помощи оснастки администрирования (MMC).
Разрабатываемый сервис имеет возможность записывать информацию в Журнал событий (Event Log) системы. Для этого достаточно объявить в классе-сервисе статическую переменную типа System.Diagnostics.EventLog и использовать ее метод WriteEntry().
В листинге представлен класс-сервис для BSUIR.Calculator:
using System;
using System.Diagnostics;
using System.ServiceProcess;
using System.Runtime.Remoting;
namespace WindowsService {
public class RemotingService : ServiceBase {
private static EventLog evt = new EventLog("Application");
public static string SVC_NAME = "Remoting Sample Service";
public RemotingService() {
this.ServiceName = SVC_NAME;
}
static void Main() {
evt.Source = SVC_NAME;
evt.WriteEntry("Remoting Service intializing");
ServiceBase.Run(new RemotingService());
}
protected override void OnStart(string[] args) {
evt.WriteEntry("Remoting Service started");
String filename = "WinServ.exe.config";
RemotingConfiguration.Configure(filename);
}
protected override void OnStop() {
evt.WriteEntry("Remoting Service stopped");
}
}
}
Класс-инсталятор остается практически без изменений (используется имя класса-сервиса RemotingService). Два файла компилируются в сборку CustomWinServ.exe, к которой подключается сборка calc.dll.
Конфигурационный файл CustomWinServ.exe.config имеет такой вид:
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" port="1234" />
</channels>
<service>
<wellknown mode="Singleton"
type="BSUIR.Calculator, Calc"
objectUri="Calculator.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
Соответствующий конфигурационный файл для клиента:
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" port="0" />
</channels>
<client>
<wellknown type="BSUIR.Calculator, Calc"
url="http://localhost:1234/Calculator.soap" />
</client>
</application>
</system.runtime.remoting>
</configuration>
Хостинг с использованием IIS обладает рядом преимуществ по сравнению с другими видами хостинга. В частности, IIS может быть сконфигурирован для обеспечения аутентификации пользователей удаленного компонента, а также для шифрования серверного трафика. Необходимо понимать, что IIS-хостинг накладывает ряд ограничений на конфигурацию удаленного класса. Допустимо использование только HTTP-канала (возможно, с нестандартным форматером). По сравнению с другими видами хостинга, использование IIS является менее производительным решением.
Общая схема IIS-хостинга проста:
1.Удаленные типы размещаются в отдельной сборке (библиотеке классов).
2.При помощи оснастки IISAdmin создается виртуальная директория, соответствующая серверной части распределенного приложения.
3.В поддиректорию bin помещается библиотека классов.
4.В виртуальной директории размещается конфигурационный файл, который называется web.config.
Создадим при помощи оснастки IISAdmin виртуальный каталог. Виртуальный каталог является частью URL и соответствует некому физическому каталогу на сервере. Например, в URL вида http://host_name/directory_name виртуальный каталог – это directory_name. Ему может соответствовать физический каталог c:\somedirectory. Стандартному URL http://host_name/ по умолчанию соответствует каталог c:\inetpub\wwwroot. После запуска оснастки IISAdmin (Пуск → Программы → Администрирование → Internet Information Services) требуется выбрать пункт Веб-узел по умолчанию, в контекстном меню пункта выбрать Создать → Виртуальный каталог. Запустится Мастер создания виртуального каталога. Требуется указать имя для каталога (укажем remote) и соответствующую каталогу директорию на диске (c:\rem). В сформированной виртуальной директории необходимо создать подкаталог bin и поместить в него сборку с удаленным типом. Альтернативное решение заключается в размещении сборки в GAC, но помните, что для доступа к сборке будет необходимо использовать сильное имя.
Конфигурационный файл web.config, размещенный в каталоге c:\rem, выглядит следующим образом:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton"
type="BSUIR.Calculator, Calc"
objectUri="Calculator.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
В конфигурационном файле отсутствует описание канала (ISS-хостинг подразумевает HHTP и стандартный порт). При необходимости изменить форматер по умолчанию для HTTP-канала описание канала должно присутствовать. Также при указании концевой точки обязательно должен быть записан суффикс soap.
Конфигурационный файл клиента выглядит следующим образом:
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="BSUIR.Calculator, Calc"
url="http://localhost/remote/Calculator.soap" />
</client>
</application>
</system.runtime.remoting>
</configuration>
3.8. Объекты-сообщения
При удаленном взаимодействии исполняющая среда манипулирует не ассемблерным кодом вызова методов, а специальными объектами-сообщениями. Для поддержки сообщений предоставлено несколько стандартных интерфейсов. Базовым является интерфейс IMessage (пространство имен System.Runtime.Remoting.Messaging). Любое сообщение – это объект, реализующий данный интерфейс. Интерфейс IMessage устроен просто. Он содержит единственное свойство Properties типа IDictionary для помещения в сообщение любых данных и идентифицирующих их ключей. Для удобства в .NET Framework описаны еще несколько интерфейсов – наследников IMessage. Схема наследования представлена на рисунке 8.
Рис. 8. Схема наследования интерфейсов
В таблице 20 указано назначение интерфейсов и перечислены некоторые их элементы.
Таблица 20
Интерфейсы для сообщений и их элементы
Интерфейс или класс
Имя элемента
Описание
IMessage
Реализуется любым сообщением
IMethodMessage
Сообщения, описывающие работу с методами
Args
Массив объектов, соответствующих аргументам метода
MethodName
Имя метода (строка)
Uri
Универсальный идентификатор (URI) объекта, которому направляется сообщение
TypeName
Строка с полным именем типа объекта, к которому направляется сообщение
IMethodReturnMessage
Сообщение, описывающее результат метода
Exception
Объект исключительной ситуации, если она сгенерирована удаленным объектом
OutArgs
Массив объектов, представляющих выходные параметры метода
ReturnValue
Объект, содержащий значение работы метода
IMethodCallMessage
Сообщение, соответствующее запуску метода
InArgs
Массив объектов, представляющих входные параметры метода
IConstructionCall-Message
Сообщение является первым направляемым к удаленному объекту, и определяет свойства для создания объекта
ActivationType
Тип удаленного объекта
Activator
Свойство для работы с активаторами объекта
IConstructionReturnMessage
Сообщение, реализующее интерфейс, посылается как ответ на IConstructionCallMessage
3.9. Пользовательские канальные приемники
Одна из возможностей расширения .NET Remoting – написание собственного канального приемника. Канальный приемник (channel message sink) выступает в роли перехватчика сообщений или потока данных на стороне клиента или сервера. Укажем некоторые сценарии, требующие использования канальных приемников:
· Шифрование данных. Необходимы канальные приемники для обработки потока данных на стороне клиента и сервера. На стороне клиента производится шифровка отсылаемого потока, на стороне сервера – расшифровка.
· Авторизация доступа. На стороне клиента канальный приемник добавляет в сообщение дополнительную информацию, идентифицирующую клиента (имя/пароль). На стороне сервера приемник извлекает данную информацию и в зависимости от ее содержания обрабатывает или отклоняет сообщение.
· Протоколирование сообщений. На стороне сервера канальный приемник заносит информацию об обработанных сообщениях в специальный файл или базу данных.
В .NET Framework канальные приемники описываются как классы, реализующие интерфейс IClientChannelSink (для клиента) или IServerChannelSink (для сервера). Канальные приемники соединены в цепочку (message sink chain). Каждый приемник хранит информацию о следующем элементе цепочки. Канальный приемник производит предварительную обработку сообщения, передает сообщение следующему приемнику в цепочке, после этого производится пост-обработка исходящего сообщения.
Установкой и настройкой канальных приемников занимаются специальные классы – провайдеры приемников. Это классы, реализующие интерфейс IClientChannelSinkProvider (для клиента) или IServerChannelSinkProvider (для сервера).
Созданные провайдеры подключаются к каналу при помощи конфигурационного файла[20]. Например, пусть имеется следующий конфигурационный файл (фрагмент):
