Клиент может теперь соединиться с удаленным объектом, используя следующий конфигурационный файл. URL, который должен быть определен здесь для удаленного объекта, является локальным хостом сервера Web, за ним следует имя приложения Web

, которое было определено при создании виртуального сайта Web и URI удаленного объекта , определенного в файле . Не обязательно определять порт номер 80, так как это порт по умолчанию для протокола http:

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

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

.

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

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

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

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

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

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

, как это делалось ранее. Нельзя при этом использовать , так как невозможно создать экземпляр самого интерфейса.

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

Можно также использовать утилиту

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

Следующая команда преобразует тип

из сборки в сборку , где генерируется прозрачный прокси, который вызывает удаленный объект.

С помощью

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

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

Параметр	Описание
– url	Извлекает схему из указанного URL.
– proxyurl	Если требуется прокси сервер для доступа к серверу, определите прокси с помощью этого параметра.
– types	Определяет тип и сборку для чтения из нее информации о схеме.
– is	Файл ввода схемы.
– ia	Файл ввода сборки.
– os	Файл вывода схемы.
– oa	Файл вывода сборки.

Отладку и поиск неисправностей в приложениях, использующих .NET, можно проводить через службы удаленного отслеживания. Класс

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

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

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