Сервисы распределенных операционных систем

Распределенная система состоит из компьютеров, соединенных коммуни­кационной средой, например локальной сетью. Рассмотрим некоторые базовые сервисы, предоставляемые распределенной операционной системой, дополнительные по отношению к описанным ранее.

3.7.1. Служба имен. В распределенной среде желательно обеспечить независимость сервисов от местоположения. Это значит, что компонент, желающий послать сообщение дру­гому компоненту, не обязан знать, где находится адресат. Если требовать, чтобы компонент А явно указывал местоположение компонента В, система получится негибкой: при перемещении компонента В придется обновлять компонент А. Поэтому необходима глобальная служба именования, обеспечивающая отделение имен от местоположения сервисов.

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

Пример службы имен – это система доменных имен (DNS), используемая в се­ти Internet. Узлам здесь присваиваются уникальные 32-битовые идентификаторы, называемые IP-адресами. IP-адрес записывается в десятичной нотации, в которой каждые восемь бит кодируются десятичным числом, а сами числа разделяются точками, например 128.174.40.15. Узлу назначается также уникальное символическое имя, например ise.gnu.edu. Серверы Internet-имен хранят таблицы, с помощью которых символические имена (называемые также доменными именами) отображаются на IP-адреса. Поскольку число пользовате­лей Internet очень велико, служба имен распределена между многими серверами.

3.7.2. Связывание клиентов и серверов. Термин связывание относится к ассоциации между клиентом и сервером. Ста­тическое связывание выполняется на этапе компиляции и означает, что все обра­щения клиента к серверу жестко «зашиты» в код.

Динамическое связывание производится во время выполнения. Оно характе­ризуется большей гибкостью, чем статическое, но меньшей эффективностью. Для динамического связывания необходимо указать имя сервера, который ведет спра­вочник имен и адресов серверов. Каждый сервер регистрирует свое местоположе­ние и предоставляемые сервисы у сервера имен. Клиент посылает запрос серверу имен, передавая имя серверного объекта, и получает ссылку на него. Затем эта ссылка используется для доступа к удаленному серверу.

3.7.3. Сервисы распределенного обмена сообщениями. Прозрачный обмен сообщениями между распределенными задачами можно реализовать с помощью распределенного ядра распределенной операционной сис­темы. На рис. 3.14 приведен пример межзадачной коммуникации с использовани­ем такого ядра. В каждом узле существует один экземпляр распределенного ядра. Сервер имен хранит главную копию таблицы имен. В тех распределенных прило­жениях, где число задач относительно постоянно, каждое распределенное ядро также может содержать собственную копию этой таблицы. На стадии начальной загрузки системы распределенное ядро посылает запрос серверу имен с просьбой загрузить таблицу имен.

Когда задача-отправитель посылает сообщение задаче-получателю, локальное ядро определяет местоположение адресата по своей таблице имен. Если получа­тель находится в том же узле, что и отправитель, то локальное ядро направляет сообщение непосредственно по назначению. Так, на рис. 3.14 сообщение от задачи В доставляется напрямую задаче С, так как обе они работают в узле 1. Если же зада­ча-получатель находится в другом узле, то локальное ядро посылает сообщение удаленному ядру, расположенному на нужном узле. Получив сообщение, удален­ное ядро переправляет его задаче-получателю. Такая ситуация проиллюстрирова­на на примере задачи А в узле 1, которая посылает сообщение задаче D в узле 2.

 

Рис. 3.14. Прозрачный поиск сервисов в распределенных приложениях

 

3.7.4. Сервисы сокетов. Сокеты – это интерфейс прикладных программ (API), предоставляемый мно­гими операционными системами. Он определяет набор операций, доступных при­ложению для организации обмена данными по сети с другим приложением (на­пример, между клиентом и сервером) по заданному протоколу, например TCP/IP. Сокеты – низкоуровневый механизм коммуникаций, поэтому впоследствии были разработаны более абстрактные интерфейсы, снимающие с приложения заботу о низкоуровневых деталях. К их числу относятся RPC (Remote Procedure Call – вызов удаленных процедур) и различные технологии ПО промежуточного слоя.

3.7.5. Обмен сообщениями через порты. В некоторых распределенных системах обмен сообщениями между удаленны­ми узлами реализован с помощью портов, что позволяет максимально ослабить связанность. Компонент (процесс или поток) в одном узле посылает сообщение, не указывая явно имя получателя, а задавая выходной порт. Компонент-получа­тель забирает сообщения из своего входного порта. На стадии конфигурации сис­темы выходной порт одного компонента подключается к входному порту другого компонента (это называется связыванием). Подобная организация повышает гибкость и имеет больше шансов на повторное использование, поскольку на этапе проектирования компонент не должен явно знать, с кем он будет соединен. Такие решения принимаются позднее, поэтому экземпляры одного и того же компонен­та могут исполняться в различных средах и приложениях. Механизм обмена со­общениями через порты реализован в нескольких операционных системах, в том числе V, Mach, CHORUS и Amoeba. В качестве примеров распреде­ленных сред программирования, предоставляющих порты и средства гибкой кон­фигурации, можно назвать Conic и Regis.

3.7.6. Восстановление после ошибок. Предполагается, что при условии нормальной работы сети сообщение будет доставлено на удаленный узел. Например, если произошла ошибка четности, то сетевое коммуникационное ПО (мы включаем его в состав распределенной опе­рационной системы) передаст сообщение повторно. Однако если удаленный узел не отвечает в течение заданного времени – из-за разрыва соединения или потому, что он вышел из строя, – передача будет прекращена по причине тайм-аута. В та­ком случае локальное ядро получит отрицательное подтверждение от коммуни­кационного ПО, свидетельствующее о том, что удаленный узел не получил сооб­щения. При этом локальное ядро известит о неудаче задачу-отправителя. Если сообщение не доставлено на удаленный узел, то сам отправитель должен решить, что делать дальше, поскольку такое решение зависит от логики приложения.

 

ПО промежуточного слоя

Распределенным системам часто приходится работать в гетерогенных средах, когда в разных узлах установлено различное оборудование и операционные сис­темы. Например, когда клиенту на ПК под управлением Windows нужно общать­ся с сервером под управлением системы UNIX. ПО промежуточного слоя – это слой программного обеспечения, располагаемый поверх ОС с целью создания од­нородной платформы, на которой могут функционировать распределенные при­ложения. Одной из ранних форм ПО промежуточного слоя был ме­ханизм вызова удаленных процедур RPC. Другие примеры – это система DCE (Distributed Computing Environment – среда распределенных вычислений), основанная на RPC, технология вызова удаленных методов (RMI) в языке Java, а также технологии СОМ и CORBA.

Предоставляя единообразный метод взаимодействия объектов, технологии ПО промежуточного слоя, такие как CORBA, СОМ и Java Beans, поощряют по­вторное использование компонентов, поэтому их часто называют компонентны­ми технологиями.

3.8.1. Платформы для распределенных вычислений. Изначально платформы для распределенных вычислений базировались на модели клиент-сервер. Но в последнее время все большую популярность завое­вывает объектная модель [2]. Коммуникации в модели клиент-сервер часто основаны на вызове удаленных процедур. При таком подходе процедуры находятся в адресном пространстве сервера и дистанционно запрашиваются кли­ентами. Сервер получает от клиента запрос, активизирует нужную процедуру и возвращает ответ.

В объектной модели объекты получают глобальные имена и могут вызывать­ся непосредственно на сервере. Существуют два подхода к распределенным вычис­лениям: модель распределенных объектов и модель мобильного кода [2]. В первом случае объекты размещаются на сервере и вызываются дистанционно, как в Java RMI и CORBA. Во втором случае требуемые объекты мигрируют с сер­вера на клиент – ярким примером такого метода служат Java-апплеты.

3.8.2. Вызовы удаленных процедур. Некоторые распределенные системы поддерживают механизм вызова удален­ных процедур (RPC). Клиент в одном узле запрашивает удаленную процедуру сервера, находящегося в другом узле. Вызов удаленной процедуры аналогичен вызову локальной процедуры, поэтому тот факт, что сервер находится далеко, скрыт от клиента. Процедура, необходимая клиенту, часто называется клиентской заглушкой (Client Stub). Она принимает запрос и произвольные параметры, упаковывает их в сообщение (дан­ный процесс называется маршалингом) и отправляет сообщение серверу.

Удаленная серверная заглушка (Server Stub) распаковывает сообщение (это действие носит имя демаршалинга) и вызывает нужную процедуру, передавая ей параметры. Когда серверная процедура заканчивает обработку запроса, она воз­вращает результаты серверной заглушке, которая упаковывает их в ответное со­общение и отправляет клиентской заглушке. Клиентская заглушка извлекает ре­зультаты из сообщения и возвращает их клиенту в виде выходных параметров.

 

Рис. 3.15. Вызов процедур: а – локальной; б – удаленной

 

Таким образом, роль клиентской и серверной заглушек сводится к тому, что­бы представить вызовы удаленных процедур так, как если бы они были локаль­ными. На рис.3.15, а изображен объект, обращающийся к локальной процедуре дру­гого объекта. На рис. 3.15, б представлено распределенное решение той же задачи, когда объект на клиентском узле вызывает удаленную процедуру, принадлежащую объекту на удаленном серверном узле. Локально вызывается клиентская заглуш­ка, которая упаковывает имя и параметры процедуры в сообщение, отправляемое по сети. Интерфейсный уровень удаленного узла получает сообщение и передает его серверной заглушке, которая распаковывает сообщение и вызывает указанную процедуру серверного объекта. После завершения процедуры серверная заглушка упаковывает ответ и посылает его по сети. Затем клиентская заглушка распако­вывает сообщение и передает его клиентскому объекту.

 

Рис. 3.16. Вызов удаленных методов (RMI)

 

 

3.8.3. Вызов удаленных методов в языке Java. Среда программирования на языке Java (она называется Java Development Kit – JDK) поддерживает технологию ПО промежуточного слоя RMI (Remote Method Invocation – вызов удаленных методов), которая позволяет распределен­ным Java-объектам общаться друг с другом. В этом слу­чае вместо отправки сообщения некоторой процедуре (как в RPC) клиентский объект посылает сообщение другому объекту и вызывает метод этого объекта (процедуру или функцию).

Роль клиентской заглушки из RPC играет клиентский заместитель (Client proxy) – рис. 3.16. Заместитель предоставляет клиентскому объекту тот же интер­фейс, что и серверный объект, и скрывает от клиента все детали коммуникации. Соответственно серверный заместитель выполняет функцию серверной заглуш­ки, пряча детали коммуникации от серверного объекта. Серверный заместитель вызывает метод объекта. Если серверного объекта не существует, заместитель со­здает его.

Разные серверные объекты могут предоставлять один и тот же интерфейс, а значит, и обслуживать данный запрос клиента. Серверный объект, который бу­дет обрабатывать запрос, выбирается во время выполнения.

 

3.9. Стандарт CORBA

CORBA (Common Object Request Broker Architecture – единая архитектура брокера объектных запросов) – это стандарт открытых систем, разработанный группой Object Management Group (OMG), который обеспечивает взаимодей­ствие между объектами на гетерогенной платформе. Брокер объектных запросов (ORB) выполняет функции ПО промежуточного слоя, поддерживающего отношения вида клиент-сервер между распределенными объектами. Серверные объекты предоставляют сервисы, которые клиенты могут запрашивать с помощью ORB. В общем случае клиенты и серверы - это всего лишь роли объектов. Таким образом, объект спо­собен выступать в роли клиента в отношениях с одним объектом и в роли серве­ра – в отношениях с другим. С помощью ORB клиентский объект в состоянии вызывать операции серверного объекта, не зная, где тот находится, на какой платформе (аппаратной или программной) исполняется, какие коммуникацион­ные протоколы нужны для связи с ним и на каком языке он написан.

3.9.1. Брокер объектных запросов. Клиент, имеющий ссылку на серверный объект, может вызывать любые сер­висы (операции интерфейса), поддерживаемые этим объектом, через посредство ORB. ORB обладает следующими достоинствами:

– прозрачностью местоположения. ORB определяет местоположение объекта по ссылке на него;

– прозрачностью реализации. Клиент не должен знать, как реализован сервер­ный объект, на каком языке он написан, на какой аппаратной и программ­ной платформе исполняется;

– прозрачностью состояния выполнения объекта. Если серверный объект не­активен, то ORB активизирует его перед доставкой запроса;

– прозрачностью коммуникационного механизма. Клиент не знает, какой про­токол будет использовать ORB.

3.9.2. Язык определения интерфейса в СОRВА. Интерфейс серверного объекта описывается на языке определения интерфейсов (Interface Definition Language – IDL), не зависящем от конкретных языков программирования. Интерфейс определяется независимо от реализации. Специ­фикации, записанные на IDL, затем переводятся на язык реализации. Реализация объекта кодируется сразу на целевом языке. Группа OMG разработала стандарт­ные отображения IDL на различные языки программирования, в том числе С, C++, Ada 95 и Java. Компиляторы IDL генерируют клиентские заглушки и серверные каркасы, аналогичные описанным выше клиентским и серверным замес­тителям. Клиентская заглушка создает запрос и передает его от имени клиента. Серверный каркас получает запрос и доставляет его объекту, реализация которо­го должна удовлетворять правилам CORBA. Функциональность, обеспечиваемая заглушками и каркасами в CORBA, похожа на заглушки, применяемые в RPC.

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

3.9.3. Статическое и динамическое связывание. В случае статического вызова заглушки и каркасы заранее скомпонованы с ис­полняемыми файлами. Статические интерфейсы определены в IDL-описаниях, созданных разработчиком. Эти описания транслируются в код заглушек, карка­сов и заголовочных файлов, как определено в правилах отображения на конкрет­ный язык. Такой подход проиллюстрирован на рис. 3.17.

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

 

Рис. 3.17. Архитектура CORBA

 

Клиент пользуется интерфейсом динамического вызова (см. рис, 3.17), кото­рый представляет собой обобщенную заглушку, не зависящую от IDL-описания интерфейса вызываемого объекта. Подобный подход позволяет клиенту обра­щаться к объекту во время выполнения, ничего не зная о его интерфейсе на ста­дии компиляции.

CORBA поддерживает также интерфейс динамического каркаса на стороне сервера, т.е. механизм динамического связывания для серверов, которые долж­ны обрабатывать входящие запросы на обслуживание от объектов, не имеющих скомпилированных из IDL-описаний каркасов. Это полезно для общения с таки­ми внешними объектами, как шлюзы или браузеры.

3.9.4. Сервисы CORBA. Брокер объектных запросов позволяет клиенту прозрачно вызывать операцию серверного объекта, предоставляя службу имен. Когда создается объект CORBA, ему присваивается уникальная объектная ссылка. Получить ссылку можно с по­мощью просмотра каталога. Иными словами, служба имен CORBA дает ссылку на поименованный объект, а клиент затем вызывает операцию этого объекта. Служба имен включает такой сервис каталогов, который аналогичен телефонно­му каталогу «белые страницы».

Другой сервис, предоставляемый CORBA, – это трейдинг. Он позволяет по­лучить ссылку на объект путем сопоставления характеристик известных объек­тов (например, типа обслуживания) с характеристиками, посланными клиентом. Сервис трейдинга, следовательно, сводится к сервису каталогов, аналогичному телефонным «желтым страницам».

3.9.5. Интеграция унаследованных приложений в каркас распределенных объектов. Многие унаследованные приложения достаточно сложно интегрировать в кар­кас, состоящий из распределенных объектов. Один из применяемых для этой цели методов состоит в написании объектов-оберток (wrappers). Объект-обертка – это объект распределенного приложения, который обрабатывает запросы клиентов к унаследованной программе. Обертки регистрируют свои сервисы в службе имен, поэтому в состоянии получать запросы от клиентов.

Большинство унаследованных приложений создавались как автономные про­граммы. В некоторых случаях унаследованный код допустимо модифицировать, чтобы объекты-обертки могли получить доступ к нему. Однако часто это непри­емлемо, так как документации практически нет, а разработчики уже недоступны. Поэтому обертки обычно общаются с унаследованным кодом при помощи таких грубых механизмов, как файлы – последовательные или индексированные. Обер­тывающий объект должен читать и модифицировать файлы, создаваемые уна­следованным приложением. Если унаследованное приложение пользуется базой данных, то к ней легко обратиться с помощью оберток, скрывающих детали до­ступа. Например, в случае реляционной базы данных обертка способна содержать предложения на языке SQL для доступа к базе. Возможен и такой вариант, когда обертка имитирует ввод с клавиатуры или переадресует на себя вывод, направ­ленный на экран или принтер.

 

⇐ Предыдущая3456789101112Следующая ⇒

Поделиться:

Популярное:

1. D. СОЦИОИДЕОЛОГИЧЕСКАЯ СИСТЕМА ВЕЩЕЙ И ПОТРЕБЛЕНИЯ
2. F. ЦИФРОВЫЕ СИСТЕМЫ РАСПРОСТРАНЕНИЯ
3. I. Местное самоуправление в системе институтов конституционного строя. История местного самоуправления
4. I. Методические принципы физического воспитания (сознательность, активность, наглядность, доступность, систематичность)
5. II. Проверка и устранение затираний подвижной системы РМ.
6. II.2. Локальные геосистемы – морфологические единицы ландшафта
7. III.3. Система классификационных единиц
8. IV. Падение отработочной системы.
9. IV. СООТНОШЕНИЕ СИМВОЛИЧЕСКИХ И ЕСТЕСТВЕННО-ЯЗЫКОВщХ СИСТЕМ КАК ФАКТОР, ОПРЕДЕЛЯЮЩИЙ ХАРАКТЕР КУЛЬТУРЫ
10. MRPII–система как черный ящик
11. VI. Предотвращение негативного воздействия на работу централизованных систем водоотведения
12. VI. Система оценки результатов освоения Рабочей учебной программы