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

Ватсон Карли

Хостинг удаленных серверов в 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

предоставляет службу слежения для получения информации о том, когда происходит маршализация и демаршализация, когда вызываются удаленные объекты и разъединяются и т. д.

□ С помощью служебного класса

TrackingServices

регистрируется и отменяется регистрация обработчика, который реализует

ITrackingHandler

.