В 1947 году в издательстве "Желдориздат" вышла книга "Атомная энергия в военных целях". Эта книга представляла собой перевод с английского заключительного отчета американских создателей атомной бомбы. В книге все замечательно - от предисловия генерала Л.Гровса, военного руководителя проекта, до последнего информационного сообщения об испытаниях бомбы, в котором говорилось о том, что создание атомной бомбы знаменует новую эпоху человечества. Эта книга - "know how" о том, как создать атомную бомбу. Говорят, что Курчатов долго просто носил эту книгу под мышкой, как библию (или как краткий курс ВКПб).
Понимая рискованность сравнения, хотелось бы провести аналогию. Сейчас, по мнению ведущих экспертов, грядет новая эпоха в области информационных технологий - эпоха открытых систем. И эта эпоха также нуждается в своей "библии". Возможно, именно на эту роль претендует "Справочное руководство по построению открытых систем", выпущенное одной из крупнейших компьютерных компаний, исповедующих религию открытых систем - Digital (Open Systems Handbook A Guide to building Open Systems, 1991).
"Открытые системы" поместили в летнем выпуске сообщение о предпринимаемых усилиях по изданию перевода этой книги. В данном номере публикуется вторая глава книги, которая является концептуальной - она дает описание проблемы в целом, основные понятия и определения.
Совета по автоматизации научных исследований РАН
д.т.н. А.Я.Олейников
Импульс к применению возможностей открытых систем возник в информационных технологиях не вчера. Он следовал, в частности, из растущего использования разнообразных аппаратных платформ, исполняющих приложения, предназначенного для решения все более широкого диапазона задач.
Внедрение гетерогенных систем и желание разделять между такими системами информацию привели к необходимости их совместной работы2. Кроме того, совместимые двоично компьютеры сулили переносимость3 программ с платформы на платформу.
Импульс к применению возможностей открытых систем исходит не только от пользователей. Он исходит от разработчиков, озабоченных необходимостью сокращать расходы и время переноса своих приложений на различные платформы. Он исходит от производителей, старающихся разрабатывать новые платформы, на которых может выполняться широкий диапазон приложений. Он исходит от национальных и международных стандартизующих организаций, обнаруживших, что им необходимо своевременно разрабатывать стандарты, отвечающие требованиям промышленности.
Эволюция открытых систем
Ранняя история концепции открытых систем - это история пользователей, стремящихся к переносимости приложений. Создание сети компьютеров IBM 360, обладающих единым набором команд и способных исполнять одну и ту же операционную систему, было большим шагом вперед в достижении переносимости, поскольку код, разработанный для одной системы серии, мог выполняться и на других. Кроме того, IBM предоставляла лицензии на свою ОС пользователям, которые предпочли купить компьютеры той же архитектуры у других производителей. Однако системы IBM 360 не были массовыми и на большей части рынка этот рывок к переносимости никак не сказался.
Ранние стандарты языков, например, стандарты Фортрана и КОБОЛа, предлагали отдельные решения проблемы переносимости и для приложений и для программистов. Стандарты позволяли создавать переносимые приложения, хотя зачастую и ограничивали функциональные возможности. Переносимость достигалась также тем, что к стандартам присоединились многочисленные производители многочисленных платформ. Когда языки созревали, их разработкой и сопровождением начинали заниматься национальные и международные организации по стандартизации, делая их независимыми от конкретного производителя. Достижение этого уровня переносимости было первым примером истинных возможностей открытых систем.
Однако переносимость без достаточной функциональности, вообще говоря, не слишком полезна. Достаточная функциональность без переносимости полезна, но ограничивает развитие технологии и возможность выбора. Оптимальный вариант для каждого пользователя - достаточная переносимость и достаточная функциональность. Для некоторых пользователей совместимость на уровне двоичного кода в рамках серии IBM360 - достаточное решение обеих проблем. Для других достаточен стандартизованный язык. Для третьих требуется еще решение вопросов, оставшихся вне рассмотрения стандартов языков.
Следующая фаза в развитии концепции открытости связана с областью интерактивной компьютерной обработки и расширяющимся диапазоном требующих переноса продуктов. В этот период Digital разработал свои VAX-системы, работающие под управлением операционной системы VMS. Каждый компьютер этой линии, вне зависимости от размера, мог исполнять один и тот же набор приложений. Параллельно с этим происходило взрывное развитие сетевых технологий, таких как DECnet или Internet (TCP/IP), объединивших системы и локальные сети академических и военных организаций Соединенных Штатов. Когда сетевая обработка стала реальностью, пользователи начали обращать внимание на совместимость и интеграцию как на необходимые атрибуты открытых систем.
Тем временем в мире персональных компьютеров операционная система MS-DOS корпорации Microsoft утверждала достоинства стандартной среды для пользователей персоналок. Низкая цена и широкая распространенность создали огромный рынок для данной ОС и ее приложений. Двоичная совместимость разрешила массу проблем, хотя также не свободна от некоторых ограничений. Многие приложения, выполняющиеся в MS-DOS, могут выполняться на любой совместимой системе. Но эта система ограничена архитектурой Intel 80x86 с 16-разрядной адресацией, графикой низкого разрешения и однопроцессорностью. Для среды MS-DOS характерен также риск быстрого распространения вирусов, поскольку система слабо (или никак не) защищена на программном и аппаратном уровнях.
Хотя ОС UNIX была разработана для создания MS-DOS, позднее с появлением достаточно мощных микропроцессоров она проявила себя как наиболее перспективное открытое операционное окружение. Исторически ОС UNIX оказалась самым жизненным вариантом для создания общей базы переносимости. Она удовлетворяет ряду требований, предъявляемых к открытым системам. При соответствующем подходе к разработке программного обеспечения приложения для основанных на UNIX`е систем могут быть весьма переносимы как в другие UNIX-системы, так, во многих случаях, и в другие системы, удовлетворяющие стандартам на интерфейсы, подобным тем, которые разработаны X/Open и POSIX.
Одна из причин рассматривать систему UNIX в качестве хорошего кандидата на использование в открытых системах состоит в том, что эта ОС почти целиком написана на языке высокого уровня, модульна и относительно гибка. ОС UNIX составлена из основных компонентов, включающих ядро, инструментальные утилиты и оболочку. Ядро, образующее стержень UNIX`а, состоит из относительно маленького набора предоставляющих системные ресурсы программ, непосредственно взаимодействующих с аппаратурой.
Утилиты выполняют основные действия по обработке данных, обращаясь в определенной последовательности к процедурам ядра. Отдельные утилиты, решающие простые задачи, могут объединяться с другими утилитами для выполнения более сложных действий. Оболочка предоставляет пользовательский интерфейс и действует в точности так же, как любая другая программа. Поскольку она не интегрирована в ядро, ее можно разработать заново (что и было проделано) при изменении требований.
Хотя ОС UNIX машинно-независима, некоторые сервисы и часть кода зависят от аппаратуры. Приложения, использующие особенности конкретной версии UNIX`а, подобно приложениям MS-DOS реализационно-зависимы.
Еще один привлекательный аспект ОС UNIX состоял в готовности AT&T предоставлять лицензии на нее. Но один из результатов такой гибкости - множество различных и несовместимых реализаций. К тому же, не все поставщики выбрали лицензионные продукты, останавливаясь вместо этого на разработке подобных UNIX`у систем с различной степенью совместимости. Деятельность ряда групп, таких как UniForum, POSIX и X/Open, направлена на поиск общего функционального ядра, которое позволит достичь переносимости между различными системами.
Кроме весьма авторитетных операционных систем, упомянутых выше, в стадии исследований и разработки находится целый ряд систем, специально проектируемых исходя из требований, предъявляемых разнородной распределенной сетевой средой. Некоторые из них - подходящие кандидаты для использования в среде открытых систем.
Сегодня внимание в открытых системах обращено не только на к операционным системам, но и к стандартным интерфейсам объединения существующих систем, приложений и пользователей. Данный подход состоит в концентрации на выработке международно признанных промышленных стандартов и добавления множества компонентов в единое модульное операционное окружение. Предполагается, что реализация стандартов в каждой системе создаст унифицированную структуру, которая уменьшит трудности в соединении разнородных схем.
Международно признанные стандарты должны быть реализованы для каждого системного компонента сети, включая каждую операционную систему и приложение. До тех пор, пока компоненты остаются верны таким стандартам, они соответствуют целям открытых систем. Однако для некоторых особо специфичных компонентов стандартов может не существовать - в таких случаях реализация стандартов слишком сложна либо слишком накладна.
Чтобы исполнить обещанное, открытые системы должны не только обеспечить операционное окружение, в котором приложения можно легко перемещать между различными аппаратными и программными платформами, а пользователи могут легко перемещаться между системами; они должны функционировать сообща с уже используемыми, стоящими миллиарды долларов продуктами.
Определение открытой системы
До сих пор мы использовали термин "открытые системы", не давая ему точного определения. Одна из основных трудностей для тех, кто связан с миром открытых систем, состоит в том, что данный термин обозначает разное для разных людей и организаций. Фактически же, с практической точки зрения, открытая система должна быть тем, что ждут от нее в каждой организации.
Однако для целей дальнейшего обсуждения нам будет удобно прийти к соглашению об определении открытых систем. Комитет IEEE POSIX 1003.0 остановился на определении, которое дает широкую и исчерпывающую трактовку понятия отрытых систем.
В соответствии с этим определением открытая система есть
"система, реализующая открытые спецификации на интерфейсы, сервисы и поддерживаемые форматы данных, достаточные для того, чтобы обеспечить должным образом разаработанным приложениям возможность переноса с минимальными изменениями на широкий диапазон систем, совместной работы с другими приложениями на локальной и удаленных системах и взаимодействия с пользователями в стиле, облегчающем тем переход от системы к системе".
Ключевой момент в этом определении - использование термина "открытая спецификация", что в свою очередь определяется как
"общедоступная спецификация, которая поддерживается открытым, гласным согласительным процессом, направленным на постоянную адаптацию новой технологии, и соответствует стандартам."
По данному определению открытая спецификация не зависит от технологии, т.е. не зависит от специфического аппаратного и программного обеспечения или от продуктов конкретного производителя. Она одинаково доступна любой заинтересованной стороне. Более того, открытая спецификация находится под контролем общественности и поэтому все, кого она затрагивает, могут участвовать в ее разработке.
Многие консорциумы и частные компании разрабатывают спецификации, не попадающие под это определение. Однако ключевой характеристикой в определении открытой спецификации является не источник, а поддержка. Например, то, что Фортран был разработан IBM, не помешало появлению открытой спецификации, поскольку стандарт Фортрана сейчас поддерживается открытым и гласным согласительный процессом.
Данное IEEE определение открытой системы, выделяющее основанные на открытых спецификациях переносимость и возможность совместной работы, будет основой всего дальнейшего обсуждения.
Определение POSIX 1003.0 подходит для этой книги по ряду причин. Возможно, важнейшая - источник определения. Определение, данное IEEE POSIX 1003.0, разработано в результате широкого обсуждения, в котором участвовали представители самых разных секторов информационных технологий - как производители, так и пользователи.
Используемый IEEE согласительный процесс гарантирует, что принятое определение содержит в себе весь диапазон перспектив. Определение не ограничено и не подвержено чрезмерному влиянию ни одной из заинтересованных сторон. Более того, это формальный процесс стандартизации, обеспечивающий критерий стабильности выработанных решений. Он также гарантирует всем равный доступ к информации и равную возможность участия в стандартизации.
Как результат широкого участия в разработке определения открытой системы, оно могло соединить различные точки зрения на идею открытости. Одновременно это не запрещает организациям при развертывании открытых систем учитывать и свое собственное мнение.
Определение, данное POSIX, позволяет нам с течением времени развивать понимание открытых систем. Не останавливаясь на конкретных продуктах или областях технологии, оно предоставляет пользователям остов, который может расширяться с изменением потребностей.
Интерпретация "открытости"
Существует много различных интерпретаций слова "открытый". В этой книге открытая система определяется как прикладное окружение, основанное на интерфейсных стандартах, обеспечивающих переносимость приложений, "переносимость " пользователей и возможность совместной работы. Такой подход может отличаться от других, но лишен ограниченности ряда общепринятых определений, каждое из которых обращается к какому-либо частному аспекту цельной картины открытых систем.
Цитируемое нами определение IEEE было разработано пользователями и производителями с учетом широкого диапазона вопросов, важных для многих разных организаций. В этом разделе рассматривается ряд распространенных интерпретаций "открытости" и обсуждается, насколько они соответствуют определению IEEE.
Стандартные платформы
Одна из распространенных точек зрения состоит в признании "открытой" системы, основанной на стандартной аппаратуре и/или стандартной операционной системе. Пример такой системы - IBM PC или любая совместимая с ней система. Большинство таких платформ используют одну и ту же операционную систему и выполняют практически одни и те же приложения.
Многие полагают, что именно операционная система определяет, является ли система открытой, и что предоставляемые ОС сервисы играют существенную роль в том, как компьютерная система функционирует и как она вписывается в объемлющее окружение. Такая трактовка открытости основана на теории, что архитектуры, работающие под управлением одной и той же ОС, будут автоматически исполнять одни и те же приложения, решая проблему переносимости; что они будут взаимодействовать друг с другом, решая проблему возможности совместной работы; что пользовательский интерфейс (монитор, клавиатура, мышь) будет оставаться единым, решая проблему "переносимости" пользователей.
В теории это так. Но совместные изощренные приложения нуждаются во многих средствах, не предоставляемых непосредственно операционной системой. Графика, сетевая обработка, почтовая служба, средства распределенной обработки, управление и передача данных - все это механизмы, которые необходимы для приложений, но не предоставляются, вообще говоря, самой операционной системой. Кроме того, операционные системы будут меняться с изменением типа и числа терминалов. Все эти изменения могут понадобиться, чтобы приспособиться к новым или более эффективным приложениям. Любое из них может воздействовать на переносимость и совместную обработку.
Достижение целей открытых систем требуется стандартизация в значительно более широком диапазоне областей и на уровне более высоком, чем уровень реализации.
Сетевая обработка
Некоторые представители компьютерного сообщества полагают, что под открытыми системами подразумевается соединение вместе различных типов систем от разных производителей. В этом случае ударение делается на названии, данном набору стандартов ISO на коммуникации продуктов от разных производителей, - Взаимодействие Открытых Систем (Open Systems Interconnection - OSI). Как и операционные системы, сети существенны для открытых систем, но не достаточны сами по себе и без связи с другими аспектами.
Сетевые стандарты направлены на возможность совместной работы и затрагивают проблемы переносимости, но не обеспечивают полного решения этих проблем.
Наличие и доступность
К области открытых систем относится и ряд вопросов, связанных с доступностью технологии или спецификаций. Существует несколько подходов к ним. Технология, предоставляемая единственным источником, но для многочисленных платформ (например, OSF Motif), - другой пример технологии, считающейся открытой. Любой производитель может приобрести лицензию на Motif и продавать этот продукт покупателям. Еще один пример - операционная система UNIX, предоставляющая первоначально AT&T, а впоследствии UNIX System Laboratories (USL), дочерней компанией AT&T. USL владеет UNIX`ом и контролирует выдачу лицензий. Реализации, базирующиеся на AT&T UNIX, доступны из многих разных источников, включая производителей аппаратуры, предлагающих свои UNIX- компьютеры, и производителей программного обеспечения, предоставляющих реализации для разных платформ. В обоих случаях поставщик может адаптировать базовую технологию к особенностям своей реализации.
Несколько отличный пример - система управления базами данных ORACLE. Ее можно получить только у корпорации Oracle или у производителей аппаратного обеспечения, имеющих торговое соглашение с Oracle; тем не менее, система доступна на весьма широком спектре платформ от различных производителей. В этом случае, приобретающие лицензию не имеют права менять технологию ORACLE.
Открытые системы часто ставят в один ряд с "собственными" системами. В лучшем случае это создает путаницу. В историческом и правовом смысле термин "собственный" означает, что технология принадлежит какой-либо одной компании. Это верно практически для всех продаваемых сегодня продуктов. Например, AT&T контролирует операционную систему UNIX System V, Microsoft контролирует операционную систему MS-DOS и так далее. То, что эти компании предпочитают предоставлять за разумную цену лицензии на свои технологии всем заинтересованным сторонам, достойно аплодисментов, но они вовсе не обязаны так поступать. Более того, архитектурные зависимости, как и дальнейшая эволюция интерфейсов, контролируется исключительно владельцем.
Группы, обладающие различными степенями влиятельности, могут публиковать требования, спецификации и даже стандарты, относящиеся к специфическим продуктам и реализациям. Даже если эти спецификации реализуются, продукты остаются собственными. Слово "собственный" в этой книге не используется, поскольку оно не точно отражает сущность реализаций открытых систем.
Другие определения открытых систем
Определение, данное IEEE и базирующее открытые системы на стандартных интерфейсах, не противоречит ни одной из приведенных выше трактовок; скорее, оно все эти трактовки примиряет, поскольку направлено на более широкие цели. Основанная на стандартах среда открытых систем может включать в себя все типы продуктов, упомянутых выше. Ценность конкретного продукта и необходимость соблюдения стандартов должны быть взвешены. Интеграцию уже существующей системы, быть может, не вполне удовлетворяющей стандартам, часто можно осуществить, не вступая в противоречие с формированием основанной на стандартах открытой среды.
При планировании открытых систем важно концентрировать внимание на стандартах интерфейсов, а не на специфических продуктах или реализациях; мнение, что ключом к открытым системам является какой-то специфический продукт, весьма рискованно. Если в процессе планирования не рассматривать стандарты интерфейсов, приложение может быть ограничено конкретной платформой и не будет переносимо в другие системы; к тому же, новая технология, способная предоставлять организации преимущества перед конкурентами, может не позволить воспользоваться такими приложениями.
Подход к открытым системам, основанный на стандартных интерфейсах, дает пользователю дополнительный запас прочности, поскольку продукты, реализующие спецификации и стандарты, согласованы между собой и могут быть протестированы для того, чтобы в этом удостовериться. Согласованность для пользователя - реальный источник независимости от производителя.
В конечном счете, открытая система, как бы она не определялась, должна отвечать устремлениям клиентов. Главный вопрос, который пользователи всегда должны задавать сами себе: "Обладает ли данный продукт достаточной функциональностью для потребностей моих открытых систем?" Лучший способ, гарантирующий правильный ответ на этот вопрос, заключается в следовании тщательно разработанному плану. Формулировка такого плана требует определения целей и приоритетов и тщательного анализа, насколько каждый элемент окружения им соответствует.
Потенциал открытых систем
В идеальном мире открытых систем все приложения будут выполняться во всех системах, работникам потребуется минимальная подготовка для работы в одном окружении, они смогут без дополнительной подготовки переходить в другое окружение, все системы можно будет объединять, чтобы свободно разделять и прозрачным образом обмениваться информацией.
Как показывает кривая 1 на рисунке, новые, технологически продвинутые платформы обладают ограниченным диапазоном приложений, в то время как сложные приложения годами разрабатываются и уточняются для платформ, специально для этих приложений подготовленных. Кривая зависимости между степенью технологической продвинутости платформы и сложностью приложений - это гипербола, форму которой задают вложения в создание реализационно зависимого кода, обучение персонала, инсталляцию баз данных и поддержку.
Совместимость новых и уже существующих реализаций сдвигает кривую влево. Но не ликвидирует зависимость в реализации, поэтому форма кривой не изменяется.
Международно признанные стандарты открытых систем, однако, действительно изменяют форму кривой, позволяя разрабатывать приложения, которые в состоянии охватить более широкий спектр технологий (кривая 2). Эти приложения будут выполняться и на платформах, которые появятся в будущем.
В то же время, существуют два ограничения, не позволяющие стандартам, мгновенно адаптируясь к усложнениям технологии и приложений, превратить данную кривую в теоретическую горизонтальную прямую (кривая 3). Во-первых, стандарты не полны. Этот недостаток не устранить никогда из-за нарастающей сложности и объема работы. Во-вторых, есть пределы предвидению технологического роста, которое может быть заложено в стандарты. Производители используют новшества, чтобы разработать еще более передовые продукты. Пользовательский спрос на новинки вряд ли уменьшается.
Тем не менее, стандарты дают преимущества пользователям и поставщика, указывая более эффективный путь из нашего нынешнего положения туда, куда мы хотим двигаться.
Стандарты Открытых Систем
События последнего времени и тенденции в индустрии информационных технологий ясно показали, что пользователи возлагают вполне определенные надежды на открытые системы. Как говорилось ранее, основные ожидания пользователей связаны со следующими областями: переносимость приложений, мобильность людей, доступность приложений, возможность совместной работы систем. Пользователям необходимо быть уверенными в том, что они получат то, что хотят.
В дополнение к традиционному воздействию, оказываемому пользователями как покупателями в рамках их взаимоотношений с производителями, пользователи открытых систем оказывают воздействие и на процессы установления и реализации стандартов.
Сегодня стандарты определяют направления развития открытых систем и всей индустрии информационных технологий. Более 250 подкомитетов официально стандартизующих организаций работают над стандартами информационных технологий. Более 1000 стандартов либо уже принято этими организациями, либо находится в процессе разработки. Но со стандартами и их реализацией связана большая путаница; видны и маневры поставщиков, призывающих стандартизовать их продукты, либо оказывающих воздействие на определение направлений стандартизации.
Стандарт де факто - термин, обозначающий продукт какого-либо поставщика, который захватил большую долю рынка и который другие поставщики стремятся эмулировать, копировать или использовать для того, чтобы захватить свою часть рынка.
Одна из главных причин значимости современной программы стандартизации - осознание опасности злоупотребления стандартами де факто. В 60-е и 70-е годы создание стандартов де факто ставило пользователей в зависимое от производителей положение при использовании основных средств обработки данных и телекоммуникаций. Важный аспект сегодняшней работы по стандартизации - преодоление этой зависимости через продвижение стандартных интерфейсов.
Стандарт де юре создается формально признанной стандартизующей организацией. Он разрабатывается при соблюдении правил консенсуса в процессе открытой дискуссии, в которой имеет шанс принять участие каждый. Ни одна группа не может действовать независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков создаст стандарт, не учитывающий требования пользователей, она потерпит неудачу. То же самое происходит, если пользователи создают стандарт, с которым не могут или не будут соглашаться поставщики, этот стандарт также не будет успешным. Когда участие различных групп в разрабатывающих стандарты организациях сбалансировано, согласительный подход к стандартам де юре позволяет всем участникам воплотить свои реалистичные ожидания и продвинуться в своих достижениях. Стандарты де юре не могут быть изменены, не пройдя через процесс согласования под контролем организации, разрабатывающей стандарты. Стандарты OSI, Ethernet, POSIX, SQL и большинство стандартов языков - примеры такого рода стандартов.
В своей книге "Стандартизация в информационных технологиях" Карл Ф.Каргил (Carl F.Cargill) представляет детальную картину процесса стандартизации и модель того, как этот процесс может развиваться в соответствии с современными требованиями индустрии информационных технологий.
1 (c)Корпорация Digital Equipment Разрешение перевести и опубликовать этот материал предоставлено Корпорацией Digital Equipment. Всякое иное распространение либо перепечатка данного материла без специального разрешения Digital запрещены.
