ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Для этого заинтересованная сторона должна получить ссылку ILease (с помощью наследуемого метода GetLifetimeService на стороне сервера или статического метода RemotingServices.GetLifetimeService на стороне клиента) и вызвать Register.

// Регистрация спонсора на стороне сервера.

CarSponsor mySponsor = new CarSponsor;

ILease itfLeaseInfo = (ILease)this.GetLifetimeService;

itfLeaseInfo.Register(mySponsor);

// Регистрация спонсора на стороне клиента.

CarSponsor mySponsor = new CarSponsor;

CarProvider cp = new CarProvider(cars);

ILease itfLeaseInfo = (ILease)Remoting.Services.GetLifetimeService(cp);

itfLeaseInfo.Register.(mySponsor);

В любом случае, если клиент или сервер желают отменить спонсорство, это можно сделать с помощью метода ILease.Unregister, например:

// Отключение спонсора для данного объекта.

itfLeaseInfo.Unregister(mySponsor);

Замечание. Объекты клиента, имеющие спонсоры, кроме необходимости реализации ISponsor должны быть производными от MarshalByRefObject, поскольку клиент должен передать спонсор в удаленный домен приложения.

Как видите, управление циклом существования MBR-типов, кумулятивно изменяющих параметры своего состояния в процессе выполнения вызовов клиентов, оказывается немного более сложным, чем простая сборка мусора. На стороне преимуществ мы имеем широкие возможности управления относительно того, когда именно следует уничтожить удаленный тип. С другой стороны, существует вероятность того, что удаленный тип будет уничтожен без ведома клиента. Если клиент попытается вызвать члены типа, уже удаленного из памяти, среда выполнения сгенерирует исключение System.Runtime.Remoting.RemotingException, и в этот момент клиент может либо создать новый экземпляр удаленного типа, либо выполнить другие предусмотренные для такого случая действия.

Исходный код. Проекты CAOCarGeneralAsmLease, CAOCarProviderServerLease и CAOCarProviderClientLease размещены в подкаталоге, соответствующем главе 18.

Альтернативные хосты для удаленных объектов

При изучении материала этой главы вы создали группу консольных серверных хостов, обеспечивающих доступ к некоторому множеству удаленных объектов. Если вы имеете опыт использования классической модели DCOM (Distributed Component Object Model – распределенная модель компонентных объектов), соответствующие шаги могут показаться вам немного странными. В мире DCOM обычно строится один COM-сервер (на стороне сервера), содержащий удаленные объекты, который несет ответственность и за прием запросов, поступающих от удаленного клиента. Это единственное DCOM-приложение *.exe "спокойно" загружается в фоновом режиме без создания, в общем-то ненужного командного окна.

При построении компоновочного блока сервера .NET велика вероятность того, что удаленной машине не придется отображать никаких сообщений. Скорее всего, вам понадобится сервер, который только откроет подходящие каналы и зарегистрирует удаленные объекты для доступа клиента. Кроме того, при наличии простого консольного хоста вам (или кому-нибудь другому) придется вручную запустить компоновочный блок *.exe на стороне сервера, поскольку система удаленного взаимодействия .NET не предусматривает автоматический запуск файла *.exe на стороне сервера при вызове удаленным клиентом.

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

• Построение .NET-приложения сервиса Windows, готового предложить хостинг для удаленных объектов.

• Разрешение осуществлять хостинг для удаленных объектов серверу IIS (Internet Information Server – информационный сервер Интернет).

Хостинг удаленных объектов с помощью сервиса Windows

Возможно, идеальным хостом для удаленных объектов является сервис Windows, поскольку сервис Windows позволяет следующее.

• Может загружаться автоматически при запуске системы

• Может запускаться, как "невидимый" процесс в фоновом режиме

• Может выполняться от имени конкретной учетной записи пользователя

Создать пользовательский сервис Windows средствами .NET исключительно просто, особенно в сравнении с возможностями непосредственного использования Win32 API. Для примера мы создадим проект Windows Service с именем CarWinService (рис. 18.7), который будет осуществлять хостинг удаленных типов, содержащихся в CarGeneralAsm.dll.