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

При изучении материала этой главы вы создали группу консольных серверных хостов, обеспечивающих доступ к некоторому множеству удаленных объектов. Если вы имеете опыт использования классической модели 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.

В результате Visual Studio 2005 сгенерирует парциальный класс (названный по умолчанию Service1), полученный из System.ServiceProcess.ServiceBase, и еще один класс (Program), реализующий метод Main() сервиса. Поскольку Service1 нельзя считать достаточно информативным именем для пользовательского сервиса, с помощью окна свойств укажите для свойств (Name) и ServiceName значение CarService. Различие между этими двумя свойствами в том, что значение (Name) задает имя, используемое для обращения к типу в программном коде, а свойство ServiceName обозначает имя, отображаемое в окне конфигурации сервисов Windows.

Перед тем как двигаться дальше, установите ссылки на компоновочные блоки CarGeneralAsm.dll и System.Remoting.dll, а также укажите следующие строки директив using в файле, содержащем определение класса CarService.

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels.Http;

using System.Runtime.Remoting.Channels;

using System.Diagnostics;

Рис. 18.7. Создание рабочего пространства нового проекта Windows Service