Библиотека программиста

Все, что необходимо начинающему и опытному программисту

2. В результате компиляции программы helo_svr.exe создается класс HelloProj .HelloClass и ему присваивается уникальный идентификатор CLSID ({88C203D9-CA54-11D2-A604-204C4F4F5020}), который указывает на регистрируемую программу helo_svr.exe. Эта информация, при построении программы в среде VB, автоматически заносится в реестр Windows, что позволяет увидеть программу в виде СОМ-объекта при использовании любого средства, способного просматривать все зарегистрированные объекты на локальной машине. Кроме того, при компиляции класса в каталоге проекта создается библиотечный файл Helo_svr.tlb со специальной структурой, доступной для анализа содержащихся в классе методов и их свойств, например с помощью программы, входящей в состав VB6, OLE/COM Object Viewer.

Пока все происходит на локальной машине. Что нужно сделать, чтобы вызывать методы сервера непосредственно из клиента, если сам сервер, т. е. разработанную нами программу helo_svr.exe, необходимо перенести на другую машину? Да почти ничего! Можно воспользоваться специальной утилитой Remote Automation Connection Manager, которая корректирует реестровые записи, или при желании самому скорректировать их вручную (категорически не рекомендуются средства Microsoft).

Что делает утилита Remote Automation Connection Manager?
Во-первых, она показывает в окне (рис. 1.5) все СОМ-объекты уже зарегистрированные на локальной машине (процесс регистрации происходит автоматически в момент построения и окончательной сборки СОМ-компонента). Обратите внимание: локальная машина — это, как правило, клиентская машина и для каждого выбранного вами из списка СОМ-объектов в поле Network Address может стоять либо имя сервера, где должен выполняться СОМ-объект, либо вообще ничего (None), — т. е. этот объект должен быть зарегистрирован и выполняться на той же самой машине, где выполняется сама утилита. Попробуем перерегистрировать и нашу с вами программу helo_svr.exe, предвидя, что впоследствии мы перенесем ее на сервер с именем DUNAJ.

Рис. 1.5. Окно утилиты Remote Automation Connection Manager

Сразу после перерегистрации в базе данных реестра появится специальная запись с сетевым адресом для CLSID нашей программы, указывающая, что ее надо искать на сервере DUNAJ. Теперь надо просто перенести наш новоявленный СОМ-сервер (а, попросту говоря, программу helo_svr.exe) на компьютер с именем DUNAJ и там запустить ее. Если компьютер DUNAJ доступен по сети, то можно на нашей локальной машине запустить программу-клиент helo_cli.exe и выполнить ее. Она установит соединение с сервером и вызовет желаемый метод. В окне формы вы получите ожидаемое сообщение (рис. 1.6).

На самом деле сообщение "Привет друг!" выдается сервером, хотя и появляется в окне клиента совсем на другом компьютере. Вы можете легко убедиться в этом, что-нибудь изменив в сообщении и перетранслировав программу на сервере. В последнем случае, ничего не меняя на стороне клиента, вы увидите совсем другое сообщение. Все очень просто. Пользователю почти ничего не надо знать о том, как функционируют распределенные приложения. С его точки зрения ничего не меняется. Компонентная объектная модель СОМ плавно переходит в DCOM. У себя на компьютере надо только правильно зарегистрировать программу, методы которой вы хотите использовать. Вот и все. Остается открытым вопрос — нужно ли регистрировать программу, выполняющую роль сервера сообщений на компьютере DUNAJ? Надо, если вы не хотите каждый раз принудительно запускать ее. Кстати, технологии Microsoft допускают удаленную регистрацию. Кому-то это может показаться удобным, другие, наоборот, справедливо критикуют Microsoft за снижение требований безопасности.

В DCOM применяется динамический способ создания и уничтожения объектов, — пока объект востребован, он должен находиться в памяти, оставаться активным.
Таким образом, если у DCOM-серверного приложения есть активные клиенты, оно должно оставаться в памяти даже в те периоды времени, когда эти клиенты бездействуют. Справедливости ради, следует сказать, что в CORBA ресурсы используются гораздо более оптимально.

Обработка ненадежных соединений в DCOM организована гораздо хуже, чем в CORBA. Так, если соединение обрывается, сервер-приложение может решить выйти из памяти, но если клиент не завершил свою работу, то при восстановлении соединения он может просто "зависнуть". Microsoft декларировала, что в СОМ 3 будет предусмотрена обработка такого рода ошибок. Влияние компании Microsoft на рынок программных средств так велико, что если это не сделает сама Microsoft, то за нее это сделают другие компании. Именно поэтому в отношении не только DCOM, но и любой другой программной технологии Microsoft можно уверенно утверждать — они непоколебимы!

Главным недостатком CORBA является то обстоятельство, что имеется множество различных несовместимых реализаций CORBA различных производителей. DCOM — это средство для обслуживания компонентов ActiveX, которые обычно реализуют код для платформ Intel ПК. Трудно представить использование CORBA без технологий Java и JavaBeans фирмы Sun. Идея переносимых байт-кодовых модулей гораздо более привлекательна, чем идея появления многоплатформенного DCOM. К сожалению, Java-технологии не слишком распространены в России, где уже долгое время усиленно размножается монокультура Wintel (операционная система Windows + компьютеры на платформе Intel).

Рис. 1.6. Окно формы клиента и форма, присылаемая с сервера

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru