Симон Робинсон - C# для профессионалов. Том II

}

for (int i=0; i < 5; i++) {

Console.WriteLine(obj.Greeting("Christian"));

}

Аренда конфигурации для удаленных серверов также может делаться с помощью конфигурационных файлов приложений. Элемент имеет атрибуты leaseTime, sponsorshipTimeOut, renewOnCallTimeи pollTime:

Используя конфигурационные файлы, можно изменить удаленную конфигурацию, редактируя файлы вместо работы с исходным кодом. Легко изменить канал для использования HTTP вместо TCP, изменить порт, имя канала, и т. д. С помощью добавления одной строки сервер может слушать два канала вместо одного.

Не обязательно начинать создавать конфигурационный файл XML для .NET Remoting с чистого листа. Для этого существует несколько инструментов:

□ При использовании версии .NET Remoting Beta 1 можно найти пример convertconfig.exeв списке примеров Framework SDK. С помощью этого инструмента можно преобразовать использовавшийся ранее компактный формат файлов в новый формат на основе XML.

□ С помощью примера configfilegen.exeможно создать конфигурационный файл из сборки. Запустите эту программу без параметров, чтобы увидеть все возможные конфигурации. Следующая командная строка создает активированный клиентом (-а) конфигурационный файл для сервера (-s).

configfilegen -ia:RemoteHello.dll -ос:HelloServer.exe.config -s -a

Системный администратор использует утилиту .NET Admin, чтобы реконфигурировать существующие конфигурационные файлы. Утилиту .NET Admin можно запустить с помощью команды:

mmc mecorcfg.msc

При помощи этой утилиты можно изменить значения времени жизни, URI удаленных объектов и свойства канала.

До этого момента все примеры серверов выполнялись на автономных (self-hosted) серверах .NET. Автономный сервер должен запускаться вручную. Удаленный сервер .NET может запускаться во множестве других типов приложений. В службе Windows сервер автоматически запускается во время старта, и кроме того, процесс может выполняться с полномочиями системной учетной записи. Создание служб Windows описано в главе 24.

B ASP.NET существует специальная поддержка для серверов .NET Remoting. ASP.NET может использоваться для автоматического запуска удаленных серверов. В противоположность приложениям exe, ASP.NET Remoting использует для конфигурации другой файл.

Для того чтобы использовать инфраструктуру Информационного сервера Интернета (IIS) и ASP.NET, необходимо создать класс, произвольный из System.MarshalByRefObject, который имеет конструктор по умолчанию. Использованный ранее код для нашего сервера с целью создания и регистрации канала больше не требуется; это делается средой выполнения ASP.NET. Необходимо только создать виртуальный каталог на сервере Web, который отображает каталог, куда помещается конфигурационный файл web.config. Сборка удаленного класса должна находиться в подкаталоге bin.

Чтобы сконфигурировать виртуальный каталог на сервере Web, воспользуйтесь Информационными службами ММС. Выберите Default Web Site и, открыв меню Action, создайте новый виртуальный каталог.

Конфигурационный файл web.configна сервере Web должен быть помещен в домашний каталог виртуального сайта Web. Согласно используемой по умолчанию конфигурации IIS, используемый канал слушает порт 80.

Клиент может теперь соединиться с удаленным объектом, используя следующий конфигурационный файл. URL, который должен быть определен здесь для удаленного объекта, является локальным хостом сервера Web, за ним следует имя приложения Web RemoteHello, которое было определено при создании виртуального сайта Web и URI удаленного объекта HelloService.soap, определенного в файле web.config. Не обязательно определять порт номер 80, так как это порт по умолчанию для протокола http:

Хостинг удаленных объектов в ASF.NET поддерживает только хорошо известные объекты.

В клиент/серверных примерах, которые были выполнены до сих пор, мы всегда ссылались на удаленные объекты в клиентском приложении. В этом случае копируется код CIL удаленного объекта, хотя нужны только метаданные. Также невозможно, чтобы клиент и сервер программировались независимо. Значительно лучшим способом является использование вместо этого интерфейсов или утилиты SoapSuds.exe.

Мы имеем четкое разделение клиентского и серверного кода с помощью интерфейсов. Интерфейс просто определяет методы без реализации. Мы отделяем контакт между клиентом и серверов от реализации. Вот необходимые шаги для использование интерфейса:

1. Определить интерфейс, который будет помещен в сборку.

2. Реализовать интерфейс в классе удаленного объекта. Чтобы сделать это, необходимо сослаться на сборку интерфейса.

3. На серверной стороне не требуется больше никаких изменений. Сервер можно программировать и конфигурировать обычным образом.

4. На клиентской стороне сошлитесь на сборку интерфейса вместо сборки удаленного объекта.

5. Клиент может теперь использовать интерфейс удаленного объекта, а не класс удаленного объекта. Объект можно создать с помощью класса Activator, как это делалось ранее. Нельзя при этом использовать new, так как невозможно создать экземпляр самого интерфейса.

Интерфейс определяет контракт между клиентом и сервером. Два приложения могут теперь разрабатываться независимо друг от друга. Если при этом придерживаться старых правил COM об интерфейсах (что интерфейсы никогда не должны меняться), то не будет никаких проблем с версиями.

Можно также использовать утилиту soapsuds, чтобы получить метаданные из сборки, soapsudsпреобразовывает сборки в XML Schemas, XML Schemas для погружения классов и другие директивы.

Следующая команда преобразует тип Helloиз сборки RemoteHello.dllв сборку HelloWrapper.dll, где генерируется прозрачный прокси, который вызывает удаленный объект.

soapsuds -types:Wrox.ProfessionalCSharp.Hello, RemoteHello -oa:HelloWrapper.dll

С помощью soapsudsможно также получить информацию о типах непосредственно с выполняющегося сервера:

soapsuds -url:http://localhost:6792/hi -oa:HelloWrapper.dll

На клиенте теперь можно ссылаться вместо исходной сборки на созданную soapsuds сборку. Некоторые из возможностей перечислены в таблице.