C# для профессионалов. Том II - Симон Робинсон
Шрифт:
Интервал:
Закладка:
RemotingConfiguration.Configure("HelloClient.exe.config");
Hello obj = new Hello();
if (obj == null) {
Console.WriteLine("could not locate server");
return 0;
}
for (int i=0; i < 5; i++) {
Console.WriteLine(obj.Greeting("Christian"));
}
Службы времени жизни в конфигурационных файлах
Аренда конфигурации для удаленных серверов также может делаться с помощью конфигурационных файлов приложений. Элемент <lifetime> имеет атрибуты leaseTime, sponsorshipTimeOut, renewOnCallTime и pollTime:
<configuration>
<system.runtime.remoting>
<application>
<lifetime leaseTime="15M" sponsorshipTimeOut="4M" renewOnCallTime="3M" pollTime="30s" />
</application>
</system.runtime.remoting>
</configuration>
Используя конфигурационные файлы, можно изменить удаленную конфигурацию, редактируя файлы вместо работы с исходным кодом. Легко изменить канал для использования 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.
Хостинг удаленных серверов в ASP.NET
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.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="SingleCall" type="Wrox.ProfessionalCSharp.Hello, RemoteHello" objectUri = "HelloService.soap" />
</service>
</application>
</system.runtime.remoting>
</configuration>
Клиент может теперь соединиться с удаленным объектом, используя следующий конфигурационный файл. URL, который должен быть определен здесь для удаленного объекта, является локальным хостом сервера Web, за ним следует имя приложения Web RemoteHello, которое было определено при создании виртуального сайта Web и URI удаленного объекта HelloService.soap, определенного в файле web.config. Не обязательно определять порт номер 80, так как это порт по умолчанию для протокола http:
<configuration>
<system.runtime.remoting>
<application>
<client url="http:/localhost/RemoteHello">
<wellknown type="Wrox.ProfessionalCSharp.Hello, RemoteHello" url="http://localhost/RemoteHello/HelloService.soap" />
</client>
<channels>
<channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" />
</channels>
</application>
</system.runtime.remoting>
</configuration>
Хостинг удаленных объектов в ASF.NET поддерживает только хорошо известные объекты.
Классы, интерфейсы и SOAPSuds
В клиент/серверных примерах, которые были выполнены до сих пор, мы всегда ссылались на удаленные объекты в клиентском приложении. В этом случае копируется код CIL удаленного объекта, хотя нужны только метаданные. Также невозможно, чтобы клиент и сервер программировались независимо. Значительно лучшим способом является использование вместо этого интерфейсов или утилиты SoapSuds.exe.
Интерфейсы
Мы имеем четкое разделение клиентского и серверного кода с помощью интерфейсов. Интерфейс просто определяет методы без реализации. Мы отделяем контакт между клиентом и серверов от реализации. Вот необходимые шаги для использование интерфейса:
1. Определить интерфейс, который будет помещен в сборку.
2. Реализовать интерфейс в классе удаленного объекта. Чтобы сделать это, необходимо сослаться на сборку интерфейса.
3. На серверной стороне не требуется больше никаких изменений. Сервер можно программировать и конфигурировать обычным образом.
4. На клиентской стороне сошлитесь на сборку интерфейса вместо сборки удаленного объекта.
5. Клиент может теперь использовать интерфейс удаленного объекта, а не класс удаленного объекта. Объект можно создать с помощью класса Activator, как это делалось ранее. Нельзя при этом использовать new, так как невозможно создать экземпляр самого интерфейса.
Интерфейс определяет контракт между клиентом и сервером. Два приложения могут теперь разрабатываться независимо друг от друга. Если при этом придерживаться старых правил COM об интерфейсах (что интерфейсы никогда не должны меняться), то не будет никаких проблем с версиями.
SOAPSuds
Можно также использовать утилиту 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 сборку. Некоторые из возможностей перечислены в таблице.
Параметр Описание -url Извлекает схему из указанного URL. -proxyurl Если требуется прокси сервер для доступа к серверу, определите прокси с помощью этого параметра. -types Определяет тип и сборку для чтения из нее информации о схеме. -is Файл ввода схемы. -ia Файл ввода сборки. -os Файл вывода схемы. -oa Файл вывода сборки.Отслеживание служб
Отладку и поиск неисправностей в приложениях, использующих .NET, можно проводить через службы удаленного отслеживания. Класс System.Runtime.Remoting.Services.TrackingService предоставляет службу слежения для получения информации о том, когда происходит маршализация и демаршализация, когда вызываются удаленные объекты и разъединяются и т. д.
