LINEBURG


<< Пред. стр.

страница 6
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

документах организаций по стандартизации, но она позволяет ясно и чётко представить основные функции системы обра-
ботки данных по поддержке прикладного ПО, ввести понятия сервисов как абстрактного представления компонентов ин-
формационной системы, широко применяемое в реальных стандартах, обосновать необходимость введения стандартизован-
ных интерфейсов (п. 2.2) и многоуровневых коммуникационных архитектур (п. 2.3), классифицировать значительную часть
стандартов по информационным технологиям. Такая модель создаёт основу для более детального изучения отдельных клас-
сов программного обеспечения (операционные системы, СУБД, стеки коммуникационных протоколов и др.), даёт возмож-
ность грамотно классифицировать и определять место в системе практически любого программного продукта.
Часто в литературе можно встретить иную, более широкую трактовку понятий, связанных с распределённой обра-
боткой данных. Так, под распределёнными вычислительными системами в ряде источников понимают вообще любую вычис-
лительную систему, в которой обработка данных производится одновременно более чем на одном процессоре. В этом случае в
класс распределённых вычислительных систем попадают также все многопроцессорные локальные вычислительные системы
и комплексы: компьютеры с параллельной архитектурой, суперкомпьютеры, кластеры вычислительных систем и др. В данной
работе такие вычислительные системы не выделяются специально: они считаются локальными, хотя, возможно, и исполь-
зуют для связи между своими обрабатывающими узлами какие-либо элементы сетевых технологий. Под распределёнными
вычислительными системами мы прежде всего будем понимать системы с территориально распределёнными (локально или
глобально) вычислительными и информационными ресурсами.
п. 2.2, 2.3:
Переносимость (portability) и способность к взаимодействию (interoperability) упоминаются как необходимые свой-
ства открытых систем во всех без исключения определениях. Иногда к ним добавляют другие, которые, как правило, являют-
ся производными от них. В глоссарии к [24] эти два свойства определяются следующим образом (приводится исходный текст
на английском языке):
"Portability — (1) The ease with which a system or component can be transferred from one hardware or software environment
to another. (2) A quality metric that can be used to measure the relative effort to transport the software for use in another environment or
to convert software for use in another operating environment, hardware configuration, or software system environment. (3) The ease
with which a system, component, data, or user can be transferred from one hardware or software environment to another."
"Interoperability — (1) The ability of two or more systems or components to exchange and use information. (2) The ability of
systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively
together. "
В данной работе намеренно не рассматриваются в подробностях методы построения, функционирования, управле-
ния вычислительными сетями и технологии передачи данных, так как этот вопрос представляет из себя отдельную, довольно
обширную отрасль информационных технологий. Здесь вычислительные сети затрагиваются только с точки зрения предос-
тавляемых системам и приложениям сетевых сервисов.
Хорошим руководством по теоретическим основам сетей передачи данных — нижнему уровню сетевых сервисов
распределённых систем обработки данных - является книга [I]. В ней, в частности, рассматриваются вопросы многоуровне-
вой архитектуры вычислительных сетей, управление каналами передачи данных, моделирование задержек в сетях передачи
данных, методы доступа к среде передачи, маршрутизация, управление потоками. Теоретические основы организации локаль-
ных сетей рассматриваются в [4], основные стандарты по локальным сетям можно найти в [5].
Глава 3. ОСНОВНЫЕ МОДЕЛИ ОТКРЫТЫХ СИСТЕМ И ИХ РАЗВИТИЕ
3.1. Классификация моделей
Появление очень большого числа стандартов в различных областях информационных
технологий привело к необходимости систематизации их в абстрактных логических моделях,
отображающих структуру информационной системы на более высоком уровне, облегчающих
классификацию, размещение и применение стандартов. Данные модели не имеют целью под-
робную структуризацию всей информационной системы. Скорее, их задача — выявить принци-
пы архитектурного построения системного и прикладного программного обеспечения и его
размещения по аппаратным компонентам системы обработки данных. Аппаратура при этом вы-
ступает в качестве своеобразного "фона", "ячеек" для размещения программного обеспечения.
Строгой классификации указанных моделей не существует, но различают несколько ос-
новных их видов:
• Профиль. Отличается высокой точностью описания, фокусируется на подмножестве
взаимосвязанных стандартов или архитектур.
• Архитектура. Характеризуется очень высокой точностью описания всех концепций,
отсутствием двусмысленностей, хорошо специфицированными описаниями сервисов и меха-
низмов их реализации (за исключением деталей реализации).
• Каркасная модель (framework). Имеют более низкую точность, описывают только об-
щие концепции, не содержат подробных объяснений и детальных спецификаций. Этим поняти-
ем часто обозначаются модели высокой степени абстракции, описывающие общие соглашения,
понятия и методы формирования более конкретных моделей.
Часто вместо наименования "логическая модель" используют понятие "структура", озна-
чающее совокупность базовых концепций, кратких описаний сервисов, стандартов и интерфей-
сов, имеющих общую цель, и некоторые детали их реализации. По предмету описания модели
можно подразделить на несколько категорий: модели систем, модели процессов, модели ин-
формационного наполнения. Некоторые документы объединяют в себе модели различных кате-
горий в целях построения единого взгляда на предмет.
Есть несколько типов организаций, создающих такие модели. Во-первых, это организа-
ции, занимающиеся разработкой стандартов де-юре и де-факто, во-вторых, это организации и
ассоциации пользователей и, в-третьих, это крупные фирмы - разработчики и производители
решений в области информационных технологий. Исторически модели появлялись в обратном
порядке: сначала модели различных фирм, а затем уже, как правило, стандарты — результат их
обобщения и достигнутых соглашений.




Рис. 7. Классификация моделей открытых систем

Указанные модели претерпели несколько этапов своего развития, среди которых можно
выделить три основных. До 80-х гг. обработка данных в основном базировалась на централизо-
ванных архитектурах вычислительных систем. Централизованная архитектура включает в себя
операционную систему и взаимодействующие приложения. Операционная система обеспечива-
ет для приложений все основные системные функции и диктует поведение приложений. В кон-
це 80-х гг., с развитием распределённой модели вычислений, различными фирмами и организа-
циями предпринимаются попытки оформить достигнутый уровень понимания структуры и
функций распределённых вычислительных систем в абстрактных моделях. Результатом явилось
создание ряда независимых моделей, различающихся степенью детализации структуры систем,
диапазоном охвата и пр., в различной степени совместимых (или несовместимых) между собой.
Представителями этой "волны" являются модели SAA (System Application Architecture) фирмы
IBM, ISO OSI, DNA/NAS фирмы DEC, CAE организации X/Open, Atlas организации Unix Inter-
national. Некоторые из них оказались не очень удачными, другие, такие как модель OSI, оказали
мощное влияние на всё дальнейшее развитие концепции открытых систем. Наконец, следую-
щий этап (90-е гг.) характеризуется стремлением построить универсальные модели, системати-
чески обеспечивающие совместимость различных архитектур и формирование открытой среды
информационных технологий. Примерами могут служить модели POSIX OSE, XDCS, Network-
ing Blueprint и Open Blueprint фирмы IBM.
Для характеристики существующих на сегодняшний день моделей их удобно подразде-
лить на несколько классов (рис. 7) согласно предмету описания и охватываемому ими диапазо-
ну (в качестве основы для классификации выбрана модель POSIX OSE, использовавшаяся в гл.
2.):
• Структуры, описывающие операционные системы (operating system structures) — это
спецификации, созданные преимущественно с целью обеспечения переносимости приложений
между различными аппаратными платформами. Примерами таких структур являются OSF/1 и
UNIX System V Release 4 (SVR4).
• Коммуникационные архитектуры (communications architectures). Основной их целью
является описание порядка обеспечения способности к взаимодействию между системами.
Коммуникационные архитектуры предоставляют формальное определение многоуровневой мо-
дели взаимодействия вычислительных систем (см. п. 2.3) и определяют стандарты протоколов
для каждого уровня. Примерами являются архитектуры OSI, SNA, DNA.
• Каркасные модели сред (environment frameworks). Эти модели охватывают аспекты пе-
реносимости и способности к взаимодействию одновременно, т.е. полностью специфицируют
среду открытых систем. Однако, в общем случае, они не специфицируют взаимосвязи между
модулями каркасной модели. Они могут рассматриваться как общие профили вычислительных
платформ (АР), так как описывают совокупность общих сервисов и средств управления ресур-
сами системы и определяют стандарты, которым вычислительные системы должны соответст-
вовать, чтобы считаться открытыми. Примерами таких моделей могут служить модель САЕ ор-
ганизации Х/Ореn и модель AES организации OSF.
• Каркасные модели распределённых систем (distributed systems frameworks). Это моде-
ли, которые также обеспечивают и переносимость, и способность к взаимодействию одновре-
менно, но они не только описывают "каркас" из модулей, но и специфицируют связи между
ними. Часто они предоставляют альтернативные подходы по включению того или иного модуля
в "каркас". Заметим, что эти модели являются надмножествами коммуникационных архитектур
в том смысле, что полностью включают их в себя. Примерами таких моделей могут служить
модель XDCS организации Х/Ореn, модель Atlas организации Unix International, модель Open
Blueprint фирмы IBM, модель OSF DCE.
• Развитие и усложнение последнего типа моделей привело к попыткам создания обоб-
щённых моделей открытых распределённых вычислений. К ним можно отнести модели высокой
степени абстракции, формально описывающие структуру и функционирование распределённых
систем, формулирующие основные принципы синтеза, анализа и управления открытыми рас-
пределёнными системами обработки данных, наборы стандартов и компонентов для конструи-
рования архитектур систем. Указанные модели являются дальнейшим обобщением трёх основ-
ных видов логических моделей: профилей, архитектур и каркасных моделей. Модели предыду-
щего поколения описывали системы масштаба предприятия, но обобщённые модели идут
дальше — они универсальны. Они описывают эталон абстрактной информационной системы
любого уровня: от локальной до глобальной, всемирного масштаба. Примерами таких моделей
являются модель RM-ODP, разработанная ISO и ITU, модель TAFIM Министерства обороны
США, модель TOGAF организации The Open Group, модель SPIRIT Platform Blueprint органи-
зации NCF.
В настоящее время существует столь большое количество моделей, что их трудно непо-
средственно сравнивать между собой и даже принимать решения, какая из них применима для
удовлетворения требований конкретной информационной системы. Сравнение возможно толь-
ко между моделями, имеющими похожие цели. Но при этом следует заметить, что не все моде-
ли, даже принадлежащие к одному классу, дают в равной степени полные ответы на вопросы
обеспечения переносимости и способности к взаимодействию. Поэтому сравнение любых мо-
делей носит достаточно условный характер.
Далее будут рассмотрены наиболее значительные представители каждого из названных
классов моделей. Некоторые из них имеют важное значение как "переломные точки" в эволю-
ции открытых распределённых систем.

3.2. Базовые стандартные модели
3.2.1. Модель ISO OSI
Модель OSI (Open Systems Interconnection) является классическим примером коммуни-
кационной архитектуры. Она определяет семиуровневую модель взаимодействия вычислитель-
ных систем. Модель OSI — старейшая из моделей открытых систем.
Модель изложена в стандарте ISO 7498, состоящем из четырёх частей:
• ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection —
Basic Reference Model: The Basic Model;
• ISO/IEC 7498-2:1989 Information processing systems — Open Systems Interconnec-
tion — Basic Reference Model — Part 2: Security Architecture;
• ISO/IEC 7498-3:1997 Information technology - Open Systems Interconnection - Ba-
sic Reference Model: Naming and addressing;
• ISO/IEC 7498-4:1989 Information processing systems — Open Systems Interconnec-
tion — Basic Reference Model — Part 4: Management framework.
В первой части стандарта определяется базовая нормативная модель (reference model)
взаимодействия открытых систем, остальные три части определяют модели безопасности (часть
2), управления (часть 4), именования и адресации (часть 3) в среде открытых систем.
На разработку модели OSI оказали влияние уже существовавшие многоуровневые моде-
ли, такие как SNA и DNA. Выделение в модели именно семи уровней и разделение функций
между ними было до некоторой степени произвольным. Оно явилось попыткой найти опти-
мальное соотношение между противоречивыми требованиями простоты модели и сложности
описываемой структуры и стало "опорной точкой" в формировании сетевых архитектур и опре-
делении функций вычислительных сетей.
Архитектура OSI довольно абстрактна и охватывает очень широкий круг аспектов: об-
щие принципы взаимодействия открытых систем, описание каждого из семи уровней, оборудо-
вание. Модель оперирует элементами архитектуры:
системы, уровни, логические объекты, сервисы, протоколы, блоки данных, соединения -
и определяет общие взаимоотношения между этими элементами.
Рис. 8. Модель взаимосвязи открытых систем OSI

Каждый уровень модели OSI (рис. 8) представляет собой группу взаимосвязанных функ-
ций обработки данных и связи между системами, которые могут быть выполнены стандартным
образом с целью поддержки различных приложений. Каждый уровень обеспечивает хорошо
определённый набор сервисов для вышележащего уровня и, в свою очередь, использует серви-
сы уровня, находящегося ниже его. Таким образом, процесс осуществления связи между систе-
мами разбивается на отдельные, легко управляемые блоки. Все вместе семь уровней обеспечи-
вают коммуникационный сервис между оконечными пользователями (end-to-end). Изменения в
протоколе любого уровня могут быть выполнены, не затрагивая соседних уровней.
Стандартизация взаимосвязи открытых систем проявляется в том, что на каждом уровне
разрабатываются и утверждаются базовые стандарты двух видов:
• определение сервиса уровня, которое в абстрактной форме описывает доступные
извне услуги данного уровня;
• спецификация протокола уровня, которая регламентирует взаимодействие между
равноправными объектами уровня, направленное на выполнение требуемого сер-
виса.
Верхние уровни модели связаны с логическими аспектами коммуникаций и ориентиро-
ваны скорее на пользователей сети (обычно это — прикладные программы), чем на саму ин-
фраструктуру сети. Эти уровни включают механизмы для координации диалога между прило-
жениями и для подготовки данных с целью обеспечения единой интерпретации их сторонами.
Приложения могут иметь доступ к функциям этих уровней через соответствующие сервисы.
Основные функции верхних уровней — следующие:
• Прикладной уровень (уровень 7) обеспечивает приложения необходимым высокоуров-
невым интерфейсом к нижележащим коммуникационным сервисам с целью обеспечения их
связи с приложениями-партнёрами на других системах. К прикладному уровню также принято
относить набор специализированных сервисов-приложений, таких как передача файлов, управ-
ление сообщениями, виртуальный терминал, директориальный сервис и др. Этими сервисами
могут, в свою очередь, пользоваться приложения конечного пользователя. В рамках сервисов,
стандартизированных ISO, к ним относятся стандарты FTAM, X.400, VT, X.500. Сами прило-
жения пользователя считаются расположенными над прикладным уровнем.
• Уровень представления данных (уровень 6) предназначен для согласования синтаксиса
и семантики данных для использования в процессе передачи данных между системами.
• Сеансовый уровень (уровень 5) обеспечивает сервисы координации диалога между сис-
темами: синхронизацию, полномочия, активности.
Нижние уровни обеспечивают транспортные функции сети: они ответственны за физи-
ческие аспекты коммуникаций и доставку данных между оконечными транспортными пользо-
вателями. Основные функции нижних уровней заключаются в следующем:
• Транспортный уровень (уровень 4) обеспечивает надёжную и эффективную доставку
данных между любыми двумя абонентами потенциально ненадёжной сети передачи данных,
независимо от характеристик и топологии сети.
• Сетевой уровень (уровень 3) обеспечивает адресацию и маршрутизацию сообщений
между системами, которые непосредственно не связаны друг с другом в сети. Модули данных
на этом уровне обычно носят название "пакеты" или "дейтаграммы".
• Уровень звена данных (уровень 2) связан с обменом неструктурированными данными
между смежными узлами сети. На этом уровне происходит обмен модулями данных — фрей-
мами — и обеспечивается обнаружение и исправление ошибок передачи.
• Физический уровень (уровень 1) предоставляет физическое соединение для передачи
данных: среду распространения сигнала, интерфейсы, процедуры передачи сигналов по линии
связи.
Уровни модели OSI можно сгруппировать в две категории, соответствующие понятиям
"транспортный провайдер" (уровни 1 — 4) и "транспортный пользователь" (уровни 5 — 7) —
см. п. 2.3.
Первая версия нормативной модели OSI была принята в качестве стандарта в 1983 г., но
и сегодня она имеет важное влияние на развитие концепции открытых систем, так как явилась
первой попыткой формирования единого монолитного стека протоколов, который обеспечил
бы универсальное взаимодействие всего спектра существующих вычислительных систем.
Появление модели OSI послужило толчком к быстрому росту числа изделии и продуктов
информационных технологий, согласующихся с концепцией открытых систем. Она стала осно-
вой разработки очень большого числа стандартов (как де-юре, так и де-факто), относящихся ко
всем семи уровням этой модели.
На любом национальном рынке крупнейшим потребителем информационных техноло-
гий наряду с крупными корпорациями часто является правительство государства. Стремление
правительств обеспечить соответствие продуктов и изделий информационных технологий, при-
обретаемых различными подразделениями правительственных органов, текущим международ-
ным стандартам по взаимодействию открытых систем и тем самым обеспечить по меньшей ме-
ре некоторую гарантию их совместной работы обусловило появление правительственных про-
филей взаимосвязи открытых систем. Среди правительственных профилей наиболее широко
известны профили GOSIP (Government OSI Profile) Великобритании и США. GOSIP США стал
обязательным стандартом в этой стране в 1990 г., после чего почти каждый основной постав-
щик продуктов и услуг информационных технологий в США объявил о наличии совместимых с
GOSIP изделий: локальных и глобальных вычислительных сетей, реализации систем обработки
сообщений, передачи файлов и т.д.
Свои собственные профили создали Франция, Швеция, Япония, Австралия, Гонконг,
многие другие страны. Значительная часть работ по стандартизации Госпрофиля России взаи-
мосвязи открытых систем была проведена в 1995 — 99гг.
Следующий международный стандарт устанавливает общую классификацию, принципы
построения и документирования профилей:
• ISO/IEC TR 10000-1:1998 — Information technology -- Framework and taxonomy of
International Standardized Profiles - Part 1: General principles and documentation
framework — общая часть стандарта;
• ISO/IEC TR 10000-2:1998 — Information technology - Framework and taxonomy of
International Standardized Profiles — Part 2: Principles and Taxonomy for OSI Profiles
— устанавливает принципы построения и классификацию профилей, создавае-
мых в рамках модели взаимосвязи открытых систем OSI;
• ISO/IEC TR 10000-3:1998 — Information technology - Framework and taxonomy of
International Standardized Profiles - Part 3: Principles and Taxonomy for Open System
Environment Profiles — устанавливает принципы построения и классификацию
профилей, создаваемых в рамках модели сред открытых систем OSE (сп. п. 3.2.2).
Профили стандартов на основе модели OSI, безусловно, являются очень важным этапом
развития стандартизации открытых систем. Однако профили дают несколько "однобокий"
взгляд на информационную систему: с точки зрения её коммуникационной инфраструктуры. В
них не видны роль и функции операционной системы. Кроме того, прикладной уровень профи-
лей стал очень быстро "разрастаться", а простая семиуровневая модель оказалась неспособна
описать всё многообразие компонентов этого уровня и соответствующих им стандартов.

3.2.2. Модель POSIX OSE
Исторически модель POSIX развивалась от разработки интерфейса переносимой опера-
ционной системы через разработку профилей операционных сред до формулировки модели
полноценной среды открытых систем, которая и получила название OSE (Open Systems Envi-
ronment).
Первая рабочая группа POSIX была образована в IEEE в 1985 г. на основе комитета по
стандартизации операционных систем, ориентированного на ОС UNIX. Первоначально POSIX
(Portable Operating System Interface for Computer Environments) — набор спецификаций для от-
крытых систем, разработанный Техническим Комитетом по операционным системам (TCOS)
IEEE. Цель POSIX— выработка спецификаций единого, унифицированного, широко поддержи-
ваемого производителями интерфейса для операционных систем, обладающих свойствами пе-
реносимости между ними приложений, пользователей и данных. POSIX составляет большой
набор документов, разрабатываемых множеством рабочих групп и комитетов. Основной набор
соглашений и концепций для этих спецификаций сформулирован в документе IEEE "Guide to
the POSIX Open Systems Environment, P1003.0". Он утверждён в качестве международных стан-
дартов:
• ISO/IEC 9945-1:1996 — Information technology - Portable Operating System Interface
(POSIX) — Part 1: System Application Program Interface (API) [C Language];
• ISO/IEC 9945-2:1993 — Information technology -- Portable Operating System Inter-
face (POSIX) - Part 2: Shell and Utilities.
Co временем число рабочих групп POSIX возросло до 18, а их тематика расширилась,
охватив все операционные среды, интерфейсы которых соответствовали спецификациям
POSIX. Задача рабочих групп трансформировалась в создание профилей различных сред: ком-
муникационных систем, систем реального масштаба времени, многопроцессорной обработки,
суперкомпьютеров, а также отдельных функций этих систем: защита информации, прозрачный
доступ к файлам, именование ресурсов, директориальные сервисы и т.д.
Некоторые результаты их работы утверждены в качестве официальных международных
стандартов:
• ISO/IEC 14519:1999 — Information technology - POSIX Ada Language Interfaces —
Binding for System Application Program Interface (API) — Realtime Extensions;
• ISO/IEC 15068-2:1999 — Information technology - Portable Operating System Inter-
face (POSIX) System Administration - Part 2: Software Administration.
Осмысление единства различных сторон разрабатываемой проблемы привело в итоге к
формулировке единой нормативной модели (функциональной) среды открытых систем, извест-
ной как OSE (POSIX Open System Environment Reference Model).
Эта модель описана с точки зрения пользователя. Она является довольно простой, но яс-
но определяет основные компоненты систем обработки данных и основные концепции форми-
рования открытой среды. Быть может, главное преимущество этой модели состоит в том, что
она позволяет легко классифицировать стандарты по открытым системам по двум категориям:
либо как интерфейсы (форматы) и протоколы, либо как спецификации, относящиеся к перено-
симости или способности к взаимодействию.
Модель OSE не является уровневой (рис. 9). Она определяет три категории логических
объектов: прикладное ПО (Application Software — AS), платформу приложений (Application
Platform — АР) и внешнюю среду (External Environment — ЕЕ) — и два типа интерфейсов меж-
ду ними: интерфейсы прикладного программирования (Application Programming Interface —
API) и интерфейсы внешней среды (External Environment Interface — EEI). Рассмотрим более
подробно существо каждого из этих понятий модели.
Прикладное ПО — это часть программного обеспечения системы, специфичная для кон-
кретного применения пользователя. Она составляется из программ (исполняемых модулей, ко-
мандных файлов, интерпретируемых записей исходного кода и пр.), данных (рабочих данных
пользователя, параметров приложений, установок среды экрана пользователя и пр.) и электрон-
ной документации (электронных документов, справок помощи (on-line help) и пр., но бумажная
документация сюда не включается). Примерами прикладного ПО являются текстовые редакто-
ры, программы работы с электронными таблицами, программы обработки информации, храня-
щейся в базах данных, и многие другие программы, являющиеся специфически пользователь-
скими по отношению к той или иной платформе. Разработка, интерпретация и исполнение не-
которых специальных видов прикладного ПО может осуществляться при посредстве специали-
зированных сред, обеспечивающих определённый вид сервиса на платформе, например, систе-
мы управления базами данных (СУБД), системы автоматизированного проектирования (САПР),
системы управления электронными таблицами и т.п. Одно или более приложений могут рабо-
тать на одной платформе одновременно, так как каждое приложение трактуется как независи-
мый логический объект.
Платформа приложений — это все остальные элементы системы обработки данных, за
исключением прикладного ПО: аппаратное обеспечение, операционная система и другие ком-
поненты и подсистемы системного ПО. Приложения, требующие ресурсов платформы, запра-
шивают их путём вызова сервисов через API. Ресурсы, находящиеся вне платформы, запраши-
вают сервисы через EEI, и наоборот, EEI являются средствами, через которые сервисы дости-
гают ресурсов внешней среды. Внутренняя структура платформы в модели OSE преднамеренно
не рассматривается. Это связано с тем, что в научных и промышленных кругах не существует
единого мнения о составе, структуре и взаимосвязях различных модулей платформы.
Внешняя среда — это все компоненты информационной системы, находящиеся за преде-
лами данной системы обработки данных: пользователи, коммуникационные каналы и средства
связи, сменные носители данных, устройства ввода /вывода. Интерфейс между АР и ЕЕ вклю-
чает форматы данных, интерфейсы и протоколы. По отношению к отдельно взятой вычисли-
тельной системе все другие вычислительные системы также выступают как объекты внешней
среды.
Модель POSIX OSE определяет распределённую среду как множество платформ прило-
жений, которые могут взаимодействовать посредством коммуникационных механизмов, внеш-
них по отношению к платформам. Когда приложению необходимо связаться с другим прило-
жением на другой прикладной платформе, приложение подаёт запросы к своей локальной
платформе через API. Так как АР взаимодействуют через коммуникационный интерфейс EEI,
локальная АР транслирует эти запросы в соответствующие действия через EEI. OSE также оп-
ределяет однородный набор стандартных сервисов, предоставляемых пользователям платформ,
в соответствии с требованиями спецификаций POSIX о переносимости и способности к взаимо-
действию. Данная модель делает попытку описать более полный подход к совместимости вы-
числительных систем, чем подход, основанный на многоуровневых архитектурах типа модели
OSI.
Модель принята в качестве международного стандарта ISO/IEC TR 14252:1996 — Infor-
mation technology - Guide to the POSIX Open System Environment (OSE).
Классификация профилей, которые могут быть построены в рамках модели OSE, опре-
делена в стандарте ISO/IEC 10000 3.
Рис. 9. Модель POSIX OSE

Для информационных нужд правительства США был создан профиль на основе модели
OSE, который получил название профиля переносимости прикладных программ (Application
Portability Profile). Он изложен в документе: Application Portability Profile. The U.S. Government
Open Systems Environment Profile. Ver. 3.0. NIST Special Publication 500-230, 1996.
Важное значение модели OSE состоит также в том, что она, очень удачно сформулиро-
вав основы концепции открытых систем, явилась базой для создания многих последующих мо-
делей открытых систем.

3.3. Модели сред открытых систем
Если вычислительные системы полностью соответствуют спецификации POSIX 1003.1,
это ещё не означает, что они образуют полноценную среду открытых систем с адекватным на-
бором сервисов и интерфейсов, которая может служить готовой базой для построения решений
для потребителя. Модели сред открытых систем обращаются к проблеме построения открытой
системы в комплексе. Примерами моделей, которые специфицируют полную среду открытых
систем, являются модель САЕ (Common Application Environment) организации Х/Ореn и модель
AES (Application Environment Specification) организации OSF.
По сути дела модели сред открытых систем являются профилями вычислительных плат-
форм, претендующих на наименование "открытой системы". Каждая из моделей определяет на-
бор общих сервисов и средств управления ресурсами для платформ и специфицирует стандар-
ты, которым они должны следовать для того, чтобы соответствовать профилю открытой систе-
мы.
• Модель САЕ (рис. 10) описана в документе XPG, разрабатывавшемся организацией
Х/Ореn с 1984 г. Первая версия документа (XPG3) появилась в 1989 г., вторая версия (XPG4) —
в 1992 г., последняя редакция документа— XPG5. Графическое изображение модели достаточ-
но условно и схематично, основную часть документа составляют спецификации. Впоследствии
модель САЕ и спецификации XPG стали частью большого проекта организации The Open Group
по выработке единой стандартной спецификации для всех операционных систем семейства
UNIX и критериев оценки на соответствие ОС этим спецификациям (т.е. оценки того, является
ли ОС «настоящей UNIX» или нет), который получил название Single UNIX.
Наименование документа первоначально расшифровывалось как Х/Ореn Portability
Guide, но позднее такую трактовку названия было рекомендовано не использовать, так как со-
держание документа вышло за рамки проблемы обеспечения переносимости, а аббревиатура
сохранена только в качестве идентификатора документа. XPG и его компоненты разработаны
на основе кооперации и консенсуса между организациями пользователей, поставщиками вы-
числительных систем, организациями по стандартизации. Он включает спецификации, осно-
ванные как на стандартах де-юре, так и на стандартах де-факто.

<< Пред. стр.

страница 6
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign