2.2. Удаленный вызов процедур 107

С уществуют службы, которые сами по себе образуют часть DCE. Служба рас­пределенных файлов {distributed file service) представляет собой всемирную фай­ловую систему, предоставляющую прозрачные методы доступа к любому файлу системы одинаковым образом. Она может быть построена поверх базовых фай­ловых систем хостов или работать независимо от них. Служба каталогов {directory service) используется для отслеживания местонахождения любого из ресурсов системы. В число этих ресурсов входят машины, принтеры, серверы, данные и многое другое. Географически они могут быть распределены по всему миру. Служба каталогов позволяет процессу запрашивать ресурсы, не задумыва­ясь о том, где они находятся, если это не необходимо для процесса. Служба за­щиты {security service) позволяет защищать ресурсы любого типа, кроме того, по­лучение некоторых данных может быть открыто только тем, кому это разрешено. И наконец, служба распределенного времени {distributed time service) позволяет поддерживать глобальную синхронизацию часов различных машин. Как мы уви­дим в следующей главе, существование некоторого представления о глобальном времени сильно упрощает гарантию целостности при параллельной работе в рас­пределенных системах.

Задачи DCE RPC

Задачи систем DCE RPC вполне традиционны. Они позволяют клиенту полу­чить доступ к удаленной службе простым вызовом локальной процедуры. Этот интерфейс дает возможность писать клиентские (то есть прикладные) програм­мы простым, хорошо знакомым большинству программистов способом. Также он упрощает запуск в распределенной среде больших объемов существующего кода с минимальными изменениями или без них.

Самое важное для системы RPC — это скрыть все возможные детали от кли­ента и до некоторой степени от сервера. Для начала система RPC может автома­тически определить необходимый сервер и установить связь между клиентом и сервером. Обычно это называется привязкой {binding). Кроме того, она может управлять транспортировкой сообщений в обе стороны, а также, если в этом есть необходимость, их дроблением и последующей сборкой, например, если один из параметров сообщения является большим массивом. И наконец, система RPC может автоматически отслеживать преобразование типов данных между клиен­том и сервером, даже если они работают на системах с разной архитектурой, ко­торые имеют различный порядок следования байт.

В заключение скажем несколько слов о способности систем RPC скрывать детали. Клиент и сервер могут быть почти независимыми друг от друга. Клиент может быть написан на Java, а сервер на С или наоборот. Клиент и сервер могут работать на разных платформах и использовать различные операционные систе­мы. Поддерживается также многообразие сетевых протоколов и представлений данных, все это — без какого-либо вмешательства в клиент или сервер.

Написание клиента и сервера

Система DCE RPC состоит из множества компонентов. В нее входят, в частно­сти, языки, библиотеки, программы-демоны и утилиты. Все это делает возмож-

108 Глава 2. Связь

ным создание разнообразных клиентов и серверов. В этом пункте мы опишем части этих программ и то, как они стыкуются друг с другом. Общий процесс на­писания и использования клиента и сервера суммирован на рис. 2.14.

В системе клиент-сервер клеем, соединяющим все в единую систему, являет­ся описание интерфейса, которое создается с помощью языка определения ин­терфейсов {Interface Definition Language, IDL). Он позволяет описать процедуры в виде, очень похожем на прототипы функций в ANSI С. Файлы IDL могут так­же содержать определения типов, описания констант и другую информацию, не­обходимую для правильного маршалинга параметров и демаршалинга результа­тов. В идеале описание интерфейсов содержит также формальное определение действий, осуществляемых процедурой, но это выходит за рамки современ­ных возможностей программирования, так что определение интерфейса включа­ет в себя только его синтаксис, но не семантику. В лучшем случае программист может лишь добавить комментарии, описывающие, что делает та или иная функ­ция.

Важнейшим элементом каждого файла IDL является глобальный уникаль­ный идентификатор описываемого интерфейса. Клиент пересылает этот иденти­фикатор в первом сообщении RPC, а сервер проверяет его правильность. В этом случае если клиент по ошибке пытается выполнить привязку не к тому серверу