2015-05-18
381
На предыдущей лабораторной работе было сконструировано несколько серверных приложений-хостов, которые обеспечивали доступ клиентов к определенному набору удаленных объектов. В мире DCOM нередко строился единственный COM -сервер серверной стороны, который размещал в себе удаленные объекты и отвечал за прием входящих запросов от удаленного клиента. Это DCOM -приложение *. exe загружалось в фоновом режиме, не показывая никакого консольного окна.
Когда вы строите серверную сборку. NET, то достаточно высоки шансы того, что удаленной машине не понадобится отображать никакого пользовательского интерфейса. Все, что требуется для этого, заключается в том, чтобы построить приложение сервера, которое откроет нужные каналы и зарегистрирует необходимые удаленные объекты для клиентского доступа. Более того, при построении простого консольного владеющего приложения (хоста) вы (или кто-то другой) должен будет вручную запустить эту сборку *. exe серверной стороны, потому что. NET Remoting не запустит автоматически *. exe на стороне сервера, когда поступит вызов от удаленного клиента.
|
|
|
С учетом этих двух трудностей возникает вопрос: как построить невидимый слушатель, который бы загружался автоматически? Программистам. NET доступны два основных варианта выбора, когда им нужно построить прозрачный хост для различных удаленных объектов:
- построить приложение. NET службы Windows для размещения удаленных объектов;
- использовать IIS (Интернетовский информационный сервис) в качестве хоста удаленных объектов.
1.2. Хостинг удаленных объектов с использованием службы Windows
Возможно, идеальным хостом для удаленных объектов является служба Windows, поскольку:
- она может быть настроена для автоматической загрузки при запуске системы;
- выполняется как невидимый фоновый процесс;
- может быть запущена от имени определенного пользователя.
К счастью, построить специальную службу Windows с использованием платформы. NET исключительно просто в отличие от того, как это делается в чистом Win32 API. Для иллюстрации давайте создадим проект службы Windows по имени CarWinService (рис.1), который будет выполнять хостинг удаленных типов, содержащихся в сборке CarGeneralAsm.dll.
Рис. 1. Создание нового рабочего пространства проекта службы Windows
Среда Visual Studio отвечает генерацией частичного класса службы (по имени Service1 по умолчанию), унаследованного от System.ServiceProcess.ServiceBase, и другого класса (Program), который реализует метод Main () этой службы. Учитывая, что Service1 довольно невнятное имя для названия специальной службы, то первое, что нужно сделать заключается в том, чтобы в окне Properties (Свойства) изменить значения ее свойств: Name и ServiceName на CarService.
|
|
|
Примечание. Чтобы открыть это окно, необходимо в проекте решения выбрать файл Service1.cs и дважды кликнуть на его пиктограмме левой клавишей мыши. В результате появится окно конструктора службы (окно в центре экрана на рис.2). После этого, поместите указатель мыши в поле этого окна, нажмите на правую клавишу, что приведет к появлению окна свойств (рис.3).
Рис.2. Инструментальная среда Visual Studio при создании службы Windows
Рис.3. Окно свойств службы Windows (в правой-средней части экрана).
Отличие между этими двумя установками заключается в том, что свойство Name используется для определения имени, по которому тип будет доступен в коде, а свойство ServiceName помечает имя, отображаемое в инструментальных средствах конфигурирования служб Windows. Остановимся пока на этом и займемся созданием сборки удаленных объектом.
