2. Модели сред открытых систем

Если вычислительные системы полностью соответствуют спецификации POSIX 1003.1, это ещё не означает, что они образуют полноценную среду откры­тых систем с адекватным набором сервисов и интерфейсов, которая может слу­жить готовой базой для построения решений для потребителя. Модели сред открытых систем обращаются к проблеме построения открытой системы в ком­плексе. Примерами моделей, которые специфицируют полную среду открытых систем, являются модель САЕ (Common Application Environment) организации Х/Ореn и модель AES (Application Environment Specification) организации OSF.

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

Модель САЕ (рис. 31) описана в документе XPG, разрабатывавшемся организацией Х/Ореn с 1984 г. Первая версия документа (XPG3) появилась в 1989 г., вторая версия (XPG4) — в 1992 г., последняя редакция документа— XPG5. Графическое изображение модели достаточно условно и схематично, ос­новную часть документа составляют спецификации. Впоследствии модель САЕ и спецификации XPG стали частью большого проекта организации The Open Group по выработке единой стандартной спецификации для всех операционных систем семейства UNIX и критериев оценки на соответствие ОС этим спецификациям (т.е. оценки того, является ли ОС «настоящей UNIX» или нет), который получил название Single UNIX.

Рис. 31. Модель САЕ.

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

Модели XPG и AES не являются конкурирующими, хотя их содержание во многом идентично. Позднее модель AES фактически стала рассматриваться поч­ти как подмножество спецификаций XPG.

3. Модели распределённых систем

Основная цель организации распределённой системы обработки данных — формирование образа единой системы для лю­бого пользователя и любого приложения системы с консистентным набором API и EEI к сервисам распределённой системы.

Эти сервисы слишком обширны и многочисленны, чтобы их можно было реализовать в одном компоненте распределённой системы. Следовательно, сис­тема должна иметь модульную структуру. Для того чтобы специфицировать ком­поненты распределённой системы и взаимосвязи между ними, создаются каркас­ные модели распределённых систем. Компоненты такой модели носят название "менеджеры ресурсов", или "сервисные модули". (Модели распределённых сис­тем, как правило, оперируют абстрактными понятиями высокого уровня, не свя­занными с технической реализацией компонентов в вычислительных системах.) Один или несколько взаимосвязанных и взаимодействующих менеджеров ресур­сов обеспечивают реализацию сервисов, которые распределённая система предоставляет через API и EEI.

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

Особенность каркасных моделей распределённых систем заключается в том, что они не вводят новых стандартов, а, подобно профилям, пользуются на­бором уже существующих стандартов де-юре и де-факто и определяют взаимо­связи между ними.

Модель XDCS (X/Open Distributed Computing Services) опубликована в 1992 — 93 гг., за основу для неё взяты спецификации XPG. Основная цель — описать распределённую среду обработки данных, а именно: сервисы, требуемые в распределённой среде, взаимосвязи между сервисами, интерфейсы программи­рования к этим сервисам, протоколы и форматы данных для обеспечения взаимо­действия вычислительных систем.

Структура XDCS слагается из трёх основных компонентов (рис. 32):

• четырёх уровней сервисов;

• качеств, которые прилагаются ко всем аспектам всех уровней сервисов (изображены на рис. кольцом);

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

Каждый из четырёх уровней сервисов имеет множество компонент, кото­рые отображают менеджеры ресурсов, обеспечивающие сервисы определённого типа: сервисы операционной системы; коммуникационные сервисы; сервисы распределения; прикладные сервисы.

Понятия «качеств сервисов» относятся ко всем четырём уровням сервисов. Они включают такие категории как безопасность, доступность, управляемость и интернационализация.

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

Рис. 32. Модель XDCS

Модель UNIX International's Atlas в настоящее время не имеет практи­ческого значения и представляет лишь исторический интерес. Так, именно при разработке этой модели было сформулировано положение о том, что ни один производитель не может за приемлемую цену снабдить потребителя всеми эле­ментами системы обработки данных. Кроме того, она послужила базисом для мо­дели XDCS. Однако графическое представление модели Atlas (рис. 33) заметно отличается от модели XDCS. Модель в основном опирается на технологические решения, принятые в семействе UNIX-подобных операционных систем.

Модель имеет многоуровневую структуру. Внутри каждого из уровней на­ходятся сервисные компоненты. Atlas специфицирует стандарты для компонент, а для некоторых из них — и конкретные технологии или продукты. Эти техноло­гии не предполагают полного исключения других возможных реализации тех же сервисов, а скорее служат руководством.

Уровни модели включают следующие сервисы: базовые сервисы операционной системы; коммуникационные сервисы; системные сервисы; сервисы приложений; сервисы защиты; сервисы межсистемного взаимодействия; прикладные инструменты.

Рис. 33. Модель UI-Atlas

Модель IBM Open Blueprint стала основой стратегии фирмы IBM по по­строению открытой распределённой среды. Это глубоко продуманная и исключительно тщательно разработанная логическая модель. Она представляет собой итог важного этапа поиска подходов к организации распределённых сред.

Структура Open Blueprint позволяет сети различных систем функционировать как единый модуль, как распределённая операционная система. Локальная система рассматривается как часть распределённой сети, а сеть рассматривается как единая система. Распределенная вычислительная система состоит из множества систем, соединённых друг с другом и взаимодействующих между собой через сеть.

Сервисы на каждой системе управляют ресурсами совместно через сеть таким же образом, как обычная операционная система управляет ресурсами отдельной вычислительной системы. Каждый узел в сети может быть структурирован в соответствии с моделью Open Blueprint. Каждый сервис на конкретной вычислительной системе должен быть доступен приложениям со всех остальных вычислительных систем. Эквивалентные сервисы на каждой локальной системе работают совместно для поддержки общей распределённой сетевой среды.

Для соответствия требованиям открытости компоненты модели Open Blue­print должны строго придерживаться стандартов при разработке элементов API, форматов и протоколов, которые позволяют различным программам выполняться на одних и тех же или разных вычислительных системах для совместной работы.

Основной структурный элемент Open Blueprint — менеджер ресурсов — набор программ, которые определяют состояние, управляют и обеспечивающих доступ к некоторому набору ресурсов. Управление ресурсами — это логическая концепция. Менеджеры ресурсов предоставляют набор интерфейсов, в том числе API, через которые могут быть выполнены операции над их ресурсами.

Управляемые ресурсы могут быть распределены среди множества серверов в гетерогенной сети. Менеджеры ресурсов подразделяются на локальные и рас­пределённые.

Сервисы модели сгруппированы в несколько классов и функционально разделены по нескольким уровням (рис. 34): сетевые сервисы; сервисы распределенной системы; приложения, и сервисы поддержки приложений.

Рис. 34. Модель Open Blueprint

Указанные три группы сервисов распределённой платформы поддержива­ются сервисами локальных операционных систем и средствами управления сис­темой.

Сервис локальной операционной системы (Local Operating System Services) представляет собой локальный менеджер ресурсов, который поддерживает сер­висы распределённого менеджера ресурсов. Локальный менеджер ресурсов пред­назначен для управления ресурсами на локальной машине, такими как централь­ный процессор и периферийные устройства.

Средства административного управления системами (Systems Management) обеспечивают и поддерживают механизмы, которые позволяют системным администраторам и автоматизированным процедурам управлять сервисами в распределенной среде.

Для реализации распределённой системы согласно этой модели на практике необходимо выбрать конкретные технологии для каждой функции или компонента в архитектуре. Не существует, однако, взаимно однозначного соот­ветствия между компонентами модели OpenBlueprint и конкретными продуктами. Блоки модели в общем случае содержат множественные компоненты и не относятся к конкретным продуктам. В настоящий момент есть много продуктов корпорации IBM, а также других фирм, которые могут выполнять требуемые функции.

Модель OSF DCE (Distributed Computing Environment) отличается от рассматривавшихся моделей распределённых систем: она является более узкой и представляет собой не только набор спецификаций, но также и программный продукт, реализующий их. Тем самым, DCE является примером "middleware", т.е. прототипом слоя программного обеспечения "среднего уровня", который в уровневой модели находится выше системного ПО локальной системы, но ниже прикладного ПО и обеспечивает функциональность распреде­лённой системы. Большинство других моделей (в том числе XDCS, UI-Atlas, IBM Open Blueprint) включает спецификации DCE для ключевых сервисов распреде­лённой системы: защита информации, время, система именования и директорий. DCE формирует ядро технологий распределённых сервисов в этих моделях.

Ценность модели DCE — в том, что в ней был не только чётко сформули­рован полный набор распределённых сервисов различных уровней (рис. 35), но и выбраны оптимальные пути их практической реализации в программных продук­тах.

Рис. 35. Модель модели DCE.

Модель и поддерживающие её продукты DCE стали стандартом де-факто в промышленности и реализованы на большом количестве платформ с операцион­ными системами MVS, Open VMS, AIX, OS/2, Windows и др.