Регистрационные базы данных и идентификация серверов и сервисов
Каким образом можно инициировать запуск сервера по запросу клиента? Если реализация сервера одна, и клиенту известно, как ее идентифицировать и на каком компьютере сети ее искать, он обращается к сервису, ответственному за предоставление доступа к данной реализации (Service Control Manager). В случае получения разрешения этот сервис обращается к другому сервису, ответственному за запуск сервера функциональности (как было сказано выше, оба сервиса могут и часто бывают реализованы в одном приложении). Этим другим сервисом либо запускается соответствующее приложение (если сервер еще не запущен, или если каждому клиенту нужен свой экземпляр сервера), либо внутри уже запущенного сервера создаются объекты, взаимодействующие с данным клиентом.
Если реализаций сервиса несколько, удаленный запуск одной из них по запросу клиента может быть осуществлен в том случае, если сведения о местоположении этих реализаций доступны либо самому клиенту, либо сервису, который ищет реализацию по его запросу. В простейшем случае список возможных реализаций просто содержится в клиентском приложении. Например, компонент SimpleObjectBroker в Delphi 4 как раз содержит такой список; клиентское приложение, содержащее такой компонент, будет при каждом запуске случайным образом подключаться к одной из реализаций, указанной в списке. Однако в общем случае, особенно когда для поиска реализации используются специализированные сервисы, такой список хранится отдельно от клиентского приложения.
Естественно, для этого в системе должна существовать некая специализированная база данных, в которой содержатся сведения о сервисах и серверах, содержащих их реализацию. Общей спецификации, которой могло бы подчиняться создание такой базы данных, не существует, так как в общем случае такая база данных может содержаться на любой платформе. В случае COM и его расширений (таких как OLEnterprise) роль такой базы данных с успехом выполняет реестр Windows. В случае CORBA эти сведения хранятся в двух репозитариях (в одном регистрируются интерфейсы сервера, в другом - их реализации, то есть конкретные приложения-серверы).
Inprise AppCenter использует свою собственную базу данных (ее реализация существует для нескольких платформ), при этом она управляется специальным приложеним, регистрирующим обращения к ней других сервисов.
Отметим, что удаленный запуск сервера по запросу брокера или клиента осуществляется в том случае, если выполняются условия, при которых он может быть запущен. Как было сказано ранее, на компьютере должен быть запущен сервис, предоставляющий разрешение на удаленный запуск данного сервера , и выполняются условия, при которых это разрешение может быть получено (например, пользователь клиентского приложения имеет право обращаться к этому серверу).
Всегда ли необходима регистрация серверов и сервисов? Это зависит от конкретной реализации способа удаленного доступа. COM-сервер автоматически регистрирует себя в реестре Windows после первого запуска, но этот первый запуск должен быть осуществлен не удаленно, а локально. При этом запись о 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).
