Распределенная обработка данных. Найханова Л.В. - 107 стр.

удаленно, а локально. При этом запись о COM-сервере обязана содержаться в реестре
компьютера, содержащего сервер. При использовании DCOM и OLEnterprise удаленный
сервер функциональности должен быть зарегистрирован также и в реестре клиентской
рабочей станции, при этом использование DCOM предполагает, что для регистрации
сервера на рабочей станции нужно просто запустить его на ней. OLEnterprise, в отличие от
Microsoft DCOM, предоставляет средства для импорта записи о сервере
функциональности из реестра компьютера, содержащего сервер, в реестры рабочих
станций. При использовании же Borland Socket Server сведения о сервере обязаны
содержаться в клиентском приложении, а регистрация сервера на рабочей станции не
требуется.
     CORBA-сервер может не быть зарегистрирован в репозитариях, но при этом он не
будет запускаться автоматически ни по запросу клиентов, ни по запросу служебных
сервисов. Для регистрации интерфейсов и реализаций CORBA-серверов существуют
специальные утилиты.
     Серверы Entera 3.2 (равно как и другие приложения) можно зарегистрировать в базе
данных Inprise AppCenter, а можно не регистрировать нигде. В этом случае сервер Entera
3.2 может быть найден сервисами и клиентами только в том случае, если он уже запущен.
     В базе данных Inprise AppCenter можно регистрировать самые разнообразные
сервисы, серверы и приложения, а также создавать так называемые конфигурации
приложений, описывая правила, которым подчиняется их запуск и остановка. Эти правила
могут быть весьма сложными, так как ApCenter, по существу, представляет собой
средство управления серверами и сервисами в распределенных системах.
     Естественно, если сервер функциональности нигде не зарегистрирован и не запущен
в данный момент, а сведения о его возможных реализациях не содержатся в клиентском
приложении, то он не будет найден ни служебными сервисами, ни клиентами.
     Общих правил для идентификации серверов и содержащиеся в них сервисов на все
случаи жизни не существуют. Однако сейчас довольно часто принято присваивать
серверам и сервисам уникальные идентификаторы UUID (Universal Unique Identifier),
представляющие собой 128-разрядные значения, сгенерированные с помощью алгоритма,
определенного OSF (Open System Foundation), на основе IP-адреса компьютера и иных его
характеристик,    и   гарантирующего с           высокой      вероятностью     уникальность
сгенерированного значения. Реализация этого алгоритма содержится, например, в
функции Windows API CoCreateGUID. В случае COM эти идентификаторы называются
GUID (Global Unique Identifier), IID (Interface Identifier), CLSID (Class Identifier). Именно
по этим идентификаторам обычно клиенты и другие сервисы в большинстве случаев ищут
реализацию нужного сервера (или предоставляемого им сервиса). Тем не менее, в
некоторых реализациях можно осуществлять поиск и по другим признакам (имя
приложения, имя сервиса и др.). Бывают случаи, когда UUID генерируется с целью
соответствия стандартам, но в действительности не используется (например, при
использовании серверов Entera 3.2 и доступа к ним непосредственно с помощью
протокола TCP/IP).

     Схема взаимодействия клиентов и серверов
     Создание сервисов и серверов middleware имеет смысл главным образом в том
случае, когда клиенты и сервер функционируют на разных компьютерах. Рассмотрим
способы обращения клиента к объектам, содержащимся в оперативной памяти другого
компьютера (и в общем случае созданным в другой операционной системе). В настоящее
время существует немало способов реализации подобного взаимодействия. Однако, эти
способы базируются на одной и той же придуманной много лет назад идее осуществления
вызовов удаленных процедур путем передачи данных между объектами внутри клиента и
внутри сервера (рис. 2.1).


                                                                                         107