Тенденции в структурномпостроении ОС
Как уже отмечалось выше, дляудовлетворения требований,предъявляемых к современной ОС,большое значение имеет ееструктурное построение.Операционные системы прошлидлительный путь развития отмонолитных систем к хорошоструктурированным модульнымсистемам, способным к развитию,расширению и легкому переносу нановые платформы. Монолитные системы
В общем случае «структура»монолитной системы представляетсобой отсутствие структуры(рисунок 4.1). ОС написана как наборпроцедур, каждая из которых можетвызывать другие, когда ей это нужно.При использовании этой техникикаждая процедура системы имеетхорошо определенный интерфейс втерминах параметров и результатов,и каждая вольна вызвать любуюдругую для выполнения некоторойнужной для нее полезной работы.
Рис. 4.1. Монолитнаяструктура ОС
Для построения монолитнойсистемы необходимо скомпилироватьвсе отдельные процедуры, а затемсвязать их вместе в единыйобъектный файл с помощьюкомпоновщика (примерами могутслужить ранние версии ядра UNIX илиNovell NetWare). Каждая процедура видитлюбую другую процедуру ( в отличиеот структуры, содержащей модули, вкоторой большая часть информацииявляется локальной для модуля, ипроцедуры модуля можно вызватьтолько через специальноопределенные точки входа).
Однако даже такие монолитныесистемы могут быть немногоструктурированными. При обращениик системным вызовам,поддерживаемым ОС, параметрыпомещаются в строго определенныеместа, такие, как регистры или стек,а затем выполняется специальнаякоманда прерывания, известная каквызов ядра или вызов супервизора.Эта команда переключает машину изрежима пользователя в режим ядра,называемый также режимомсупервизора, и передает управлениеОС. Затем ОС проверяет параметрывызова для того, чтобы определить,какой системный вызов должен бытьвыполнен. После этого ОСиндексирует таблицу, содержащуюссылки на процедуры, и вызываетсоответствующую процедуру. Такаяорганизация ОС предполагаетследующую структуру:
1. Главная программа, котораявызывает требуемые сервисныепроцедуры.
2. Набор сервисных процедур,реализующих системные вызовы.
3. Набор утилит, обслуживающихсервисные процедуры.
В этой модели для каждогосистемного вызова имеется однасервисная процедура. Утилитывыполняют функции, которые нужнынескольким сервисным процедурам.Это деление процедур на три слояпоказано на рисунке 4.2.
Рис. 4.2. Простаяструктуризация монолитной ОС Многоуровневые системы
Обобщением предыдущего подходаявляется организация ОС какиерархии уровней. Уровниобразуются группами функцийоперационной системы — файловаясистема, управление процессами иустройствами и т.п. Каждый уровеньможет взаимодействовать только сосвоим непосредственным соседом — выше- или нижележащим уровнем.Прикладные программы или модулисамой операционной системыпередают запросы вверх и вниз поэтим уровням.
Первой системой, построеннойтаким образом была простаяпакетная система THE, которуюпостроил Дейкстра и его студенты в1968 году.
Система имела 6 уровней. Уровень 0занимался распределением временипроцессора, переключая процессы попрерыванию или по истечениивремени. Уровень 1 управлял памятью- распределял оперативную память ипространство на магнитном барабанедля тех частей процессов (страниц),для которых не было места в ОП, тоесть слой 1 выполнял функциивиртуальной памяти. Слой 2 управлялсвязью между консолью оператора ипроцессами. С помощью этого уровнякаждый процесс имел своюсобственную консоль оператора.Уровень 3 управлял устройствамиввода-вывода и буферизовал потокиинформации к ним и от них. С помощьюуровня 3 каждый процесс вместо того,чтобы работать с конкретнымиустройствами, с их разнообразнымиособенностями, обращался кабстрактным устройствамввода-вывода, обладающим удобнымидля пользователя характеристиками.На уровне 4 работалипользовательские программы,которым не надо было заботиться нио процессах, ни о памяти, ни оконсоли, ни об управленииустройствами ввода-вывода. Процесссистемного оператора размещался науровне 5.
В системе THE многоуровневая схемаслужила, в основном, целямразработки, так как все частисистемы компоновались затем вобщий объектный модуль.
Дальнейшее обобщениемногоуровневой концепции былосделано в ОС MULTICS. В системе MULTICSкаждый уровень (называемый кольцом)является более привилегированным,чем вышележащий. Когда процедураверхнего уровня хочет вызватьпроцедуру нижележащего, она должнавыполнить соответствующийсистемный вызов, то есть команду TRAP(прерывание), параметры которойтщательно проверяются перед тем,как выполняется вызов. Хотя ОС вMULTICS является частью адресногопространства каждогопользовательского процесса,аппаратура обеспечивает защитуданных на уровне сегментов памяти,разрешая, например, доступ к однимсегментам только для записи, а кдругим — для чтения или выполнения.Преимущество подхода MULTICSзаключается в том, что он может бытьрасширен и на структурупользовательских подсистем.Например, профессор может написатьпрограмму для тестирования иоценки студенческих программ изапустить эту программу на уровне n,в то время как студенческиепрограммы будут работать на уровнеn+1, так что они не смогут изменитьсвои оценки.
Многоуровневый подход был такжеиспользован при реализацииразличных вариантов ОС UNIX.
Хотя такой структурный подход напрактике обычно работал неплохо,сегодня он все большевоспринимается монолитным. Всистемах, имеющих многоуровневуюструктуру было нелегко удалитьодин слой и заменить его другим всилу множественности и размытостиинтерфейсов между слоями.Добавление новых функций иизменение существующих требовалохорошего знания операционнойсистемы и массы времени. Когдастало ясно, что операционныесистемы живут долго и должны иметьвозможности развития и расширения,монолитный подход стал даватьтрещину, и на смену ему пришламодель клиент-сервер и тесносвязанная с ней концепциямикроядра. Модель клиент-сервер имикроядра
Модель клиент-сервер — это ещеодин подход к структурированию ОС.В широком смысле модельклиент-сервер предполагает наличиепрограммного компонента — потребителя какого-либо сервиса — клиента, и программного компонента- поставщика этого сервиса — сервера. Взаимодействие междуклиентом и серверомстандартизуется, так что серверможет обслуживать клиентов,реализованных различнымиспособами и, может быть, разнымипроизводителями. При этом главнымтребованием является то, чтобы онизапрашивали услуги серверапонятным ему способом. Инициаторомобмена обычно является клиент,который посылает запрос наобслуживание серверу, находящемусяв состоянии ожидания запроса. Одини тот же программный компонентможет быть клиентом по отношению кодному виду услуг, и сервером длядругого вида услуг. Модельклиент-сервер является скорееудобным концептуальным средствомясного представления функций тогоили иного программного элемента втой или иной ситуации, нежелитехнологией. Эта модель успешноприменяется не только припостроении ОС, но и на всех уровняхпрограммного обеспечения, и имеет внекоторых случаях более узкий,специфический смысл, сохраняя,естественно, при этом все своиобщие черты.
Рис. 4.3. Структура ОСклиент-сервер
Применительно к структурированиюОС идея состоит в разбиении ее нанесколько процессов — серверов,каждый из которых выполняетотдельный набор сервисных функций — например, управление памятью,создание или планированиепроцессов. Каждый сервервыполняется в пользовательскомрежиме. Клиент, которым может бытьлибо другой компонент ОС, либоприкладная программа, запрашиваетсервис, посылая сообщение насервер. Ядро ОС (называемое здесьмикроядром), работая впривилегированном режиме,доставляет сообщение нужномусерверу, сервер выполняет операцию,после чего ядро возвращаетрезультаты клиенту с помощьюдругого сообщения (рисунок 4.3).
Подход с использованиеммикроядра заменил вертикальноераспределение функцийоперационной системы нагоризонтальное. Компоненты,лежащие выше микроядра, хотя ииспользуют сообщения, пересылаемыечерез микроядро, взаимодействуютдруг с другом непосредственно.Микроядро играет рольрегулировщика. Оно проверяетсообщения, пересылает их междусерверами и клиентами, ипредоставляет доступ к аппаратуре.
Данная теоретическая модельявляется идеализированнымописанием системы клиент-сервер, вкоторой ядро состоит только изсредств передачи сообщений. Вдействительности различныеварианты реализации моделиклиент-сервер в структуре ОС могутсущественно различаться по объемуработ, выполняемых в режиме ядра.
На одном краю этого спектранаходится разрабатываемая фирмойIBM на основе микроядра Machоперационная система Workplace OS,придерживающаяся чистоймикроядерной доктрины, состоящей втом, что все несущественные функцииОС должны выполняться не в режимеядра, а в непривилегированном(пользовательском) режиме. Надругом — Windows NT, в составе которойимеется исполняющая система (NTexecutive), работающая в режиме ядра ивыполняющая функции обеспечениябезопасности, ввода-вывода идругие.
Микроядро реализует жизненноважные функции, лежащие в основеоперационной системы. Это базис дляменее существенных системных служби приложений. Именно вопрос о том,какие из системных функций считатьнесущественными, и, соответственно,не включать их в состав ядра,является предметом спора средисоперничающих сторонников идеимикроядра. В общем случае,подсистемы, бывшие традиционнонеотъемлемыми частямиоперационной системы — файловыесистемы, управление окнами иобеспечение безопасности — становятся периферийными модулями,взаимодействующими с ядром и друг сдругом.
Главный принцип разделенияработы между микроядром иокружающими его модулями — включатьв микроядро только те функции,которым абсолютно необходимоисполняться в режиме супервизора ив привилегированном пространстве.Под этим обычно подразумеваютсямашиннозависимые программы(включая поддержку несколькихпроцессоров), некоторые функцииуправления процессами, обработкапрерываний, поддержка пересылкисообщений, некоторые функцииуправления устройствамиввода-вывода, связанные с загрузкойкоманд в регистры устройств. Этифункции операционной системытрудно, если не невозможно,выполнить программам, работающим впространстве пользователя.
Есть два пути решения этойпроблемы. Один путь — разместитьнесколько таких, чувствительных крежиму работы процессора, серверов,в пространстве ядра, что обеспечитим полный доступ к аппаратуре и, вто же время, связь с другимипроцессами с помощью обычногомеханизма сообщений. Такой подходбыл использован, например, приразработке Windows NT: кроме микроядра,в привилегированном режимеработает часть Windows NT, называемаяexecutive управляющей программой. Онавключает ряд компонентов, которыеуправляют виртуальной памятью,объектами, вводом-выводом ифайловой системой (включая сетевыедрайверы), взаимодействиемпроцессов, и частично системойбезопасности.
Другой путь, заключается в том,чтобы оставить в ядре тольконебольшую часть сервера,представляющую собой механизмреализации решения, а часть,отвечающую за принятие решения,переместить в пользовательскуюобласть. В соответствии с этимподходом, например, в микроядре Mach,на базе которого разработана WorkplaceOS, размещается только часть системыуправления процессами (и нитями),реализующая диспетчеризацию (тоесть непосредственно переключениес процесса на процесс), а всефункции, связанные с анализомприоритетов, выбором очередногопроцесса для активизации,принятием решения о переключениина новый процесс и другиеаналогичные функции выполняютсявне микроядра. Этот подход требуеттесного взаимодействия междувнешним планировщиком ирезидентным диспетчером.
Здесь важно сделать различие — запуск процесса или нити требуетдоступа к аппаратуре, так что пологике — это функция ядра. Но ядрувсе равно, какую из нитей запускать,поэтому решения о приоритетахнитей и дисциплине постановки вочередь может принимать работающийвне ядра планировщик.
Кроме уже представленныхсоображений, перемещениепланировщика на пользовательскийуровень может понадобиться длячисто коммерческих целей.Некоторые производители ОС(например, IBM и OSF со своимивариантами микроядра Mach) планируютлицензировать свое микроядродругим поставщикам, которым можетпотребоваться заменить исходныйпланировщик на другой,поддерживающий, например,планирование в задачах реальноговремени или реализующий какой-тоспециальный алгоритм планирования.А вот другая ОС — Windows NT, такжеиспользующая микроядернуюконцепцию — воплотила понятиеприоритетов реального времени всвоем планировщике, резидентнорасположенном в ядре, и это не даетвозможности заменить еепланировщик на другой.
Как и управление процессами,управление памятью можетраспределяться между микроядром исервером, работающим впользовательском режиме. Например,в Workplace OS микроядро управляетаппаратурой страничной памяти.Пейджер (система управлениястраничной памятью), работающий внеядра, определяет стратегиюзамещения страниц (т.е. решает,какие страницы следует удалить изпамяти для размещения страниц,выбранных с диска в ответ напрерывание по отсутствиюнеобходимой страницы), а микроядровыполняет перемещение выбранныхпейджером страниц. Как ипланировщик процессов, пейджерявляется заменяемой составнойчастью.
Драйверы устройств также могутрасполагаться как внутри ядра, таки вне его. При размещении драйверовустройств вне микроядра дляобеспечения возможностиразрешения и запрещенияпрерываний, часть программыдрайвера должна исполняться впространстве ядра. Отделениедрайверов устройств от ядра делаетвозможной динамическуюконфигурацию ОС. Кромединамической конфигурации, есть идругие причины рассматриватьдрайверы устройств в качествепроцессов пользовательскогорежима. СУБД, например, может иметьсвой драйвер, оптимизированный подконкретный вид доступа к диску, ноего нельзя будет подключить, еслидрайверы будут расположены в ядре.Этот подход также способствуетпереносимости системы, так какфункции драйверов устройств могутбыть во многих случаяхабстрагированы от аппаратнойчасти.
В настоящее время именнооперационные системы, построенныес использованием моделиклиент-сервер и концепциимикроядра, в наибольшей степениудовлетворяют требованиям,предъявляемым к современным ОС.
Высокая степень переносимостиобусловлена тем, что весьмашинно-зависимый код изолирован вмикроядре, поэтому для переносасистемы на новый процессортребуется меньше изменений и всеони логически сгруппированывместе.
Технология микроядер являетсяосновой построения множественныхприкладных сред, которыеобеспечивают совместимостьпрограмм, написанных для разных ОС.Абстрагируя интерфейсы прикладныхпрограмм от расположенных нижеоперационных систем, микроядрапозволяют гарантировать, чтовложения в прикладные программы непропадут в течение нескольких лет,даже если будут сменятьсяоперационные системы и процессоры.
Расширяемость также являетсяодним из важных требований ксовременным операционным системам.Является ли операционная системамаленькой, как DOS, или большой, какUNIX, для нее неизбежно настанетнеобходимость приобрести свойства,не заложенные в ее конструкцию.Увеличивающаяся сложностьмонолитных операционных системделала трудным, если вообщевозможным, внесение изменений в ОСс гарантией надежности еепоследующей работы. Ограниченныйнабор четко определенныхинтерфейсов микроядра открываетпуть к упорядоченному росту иэволюции ОС.
Обычно операционная системавыполняется только в режиме ядра, априкладные программы — только врежиме пользователя, заисключением тех случаев, когда ониобращаются к ядру за выполнениемсистемных функций. В отличие отобычных систем, системапостроенная на микроядре,выполняет свои серверныеподсистемы в режиме пользователя,как обычные прикладные программы.Такая структура позволяет изменятьи добавлять серверы, не влияя нацелостность микроядра.
Иногда имеется потребность и всокращении возможностей ОС. На WindowsNT или UNIX перешло бы большее числопользователей, если бы для этихоперационных систем не требовалось16 Мб оперативной памяти и 70 Мб иболее пространства на жесткомдиске. Микроядро не обязательноподразумевает небольшую систему.Надстроенные службы, типа файловойсистемы и системы управленияокнами, добавят к ней немало.Конечно же, не всем нужнабезопасность класса C2 илираспределенные вычисления. Есливажные, но предназначенные дляопределенных потребителейсвойства можно исключать изсостава системы, то базовый продуктподойдет более широкому кругупользователей.
Использование моделиклиент-сервер повышает надежность.Каждый сервер выполняется в видеотдельного процесса в своейсобственной области памяти, и такимобразом защищен от другихпроцессов. Более того, посколькусерверы выполняются в пространствепользователя, они не имеютнепосредственного доступа каппаратуре и не могутмодифицировать память, в которойхранится управляющая программа. Иесли отдельный сервер можетпотерпеть крах, то он может бытьперезапущен без останова илиповреждения остальной части ОС.
Эта модель хорошо подходит дляраспределенных вычислений, так какотдельные серверы могут работатьна разных процессорахмультипроцессорного компьютераили даже на разных компьютерах. Приполучении от процесса сообщениямикроядро может обработать егосамостоятельно или переслатьдругому процессу. Так как микроядрувсе равно, пришло ли сообщение отлокального или удаленногопроцесса, подобная схема передачисообщений является элегантнымбазисом для RPC. Однако такаягибкость не дается даром. Пересылкасообщений не так быстра, какобычные вызовы функций, и ееоптимизация является критическимфактором успеха операционнойсистемы на основе микроядра. Windows NT,например, в некоторых случаяхзаменяет перенос сообщений накоммуникационные каналы с общейпамятью, имеющие более высокуюпропускную способность. Хотя это истоит дороже в смысле потребленияфиксированной памяти микроядра,данная альтернатива может помочьсделать модель пересылки сообщенийболее практичной.
Коммерческие версии микроядер
Одной из первых представилапонятие микроядра фирма Next, котораяиспользовала в своих компьютерахсистему Mach, прошедшую большой путьразвития в университетеКарнеги-Меллона при помощиагентства Министерства обороны СШАDARPA. Теоретически, ее небольшоепривилегированное ядро, окруженноеслужбами пользовательского режима,должно было обеспечитьбеспрецедентную гибкость имодульность. Но на практике этопреимущество было несколькоуменьшено наличием монолитногосервера операционной системы BSD 4.3,который выполнялся впользовательском пространстве надмикроядром Mach. Однако Mach дал Nextвозможность предоставить службупередачи сообщений иобъектно-ориентированные средства,которые предстали перед конечнымипользователями в качествеэлегантного интерфейсапользователя с графическойподдержкой конфигурирования сети,системного администрирования иразработки программногообеспечения.
Затем пришла Microsoft Windows NT,рекламировавшая в качествеключевых преимуществ применениямикроядра не только модульность, нои переносимость. Конструкция NTпозволяет ей работать на системахна основе процессоров Intel, MIPS и Alpha (ипоследующих), и поддерживатьсимметричную многопроцессорность.Из-за того, что NT должна былавыполнять программы, написанныедля DOS, Windows, OS/2 и использующихсоглашения POSIX, Microsoft использоваламодульность, присущуюмикроядерному подходу для того,чтобы сделать структуру NT неповторяющей ни одну изсуществующих операционных систем.Вместо этого NT поддерживает каждуюнадстроенную операционную системув виде отдельного модуля илиподсистемы.
Более современные архитектурымикроядра были предложены Novell, USL,Open Software Foundation, IBM, Apple и другими.Одним из основных соперников NT наарене микроядер является микроядроMach 3.0, которое и IBM и OSF взялисьпривести к коммерческому виду. (Next вкачестве основы для NextStep покаиспользует Mach 2.5, но при этомвнимательно присматривается к Mach3.0.). Основной соперник Mach — микроядро Chorus 3.0 фирмы Chorus Systems,выбранный USL за основу для своихпредложений. Это же микроядро будетиспользоваться в SpringOS фирмы Sun,объектно-ориентированномпреемнике Solaris.
Сегодня стало ясно, что имеетсятенденция движения от монолитныхсистем в сторону подхода сиспользованием небольших ядер.Именно такой подход ужеиспользовался компаниями QNX Software иUnisys, в течение нескольких летпоставляющих пользующиеся успехомоперационные системы на основемикроядра. QNX фирмы QNX Softwareобслуживает рынок систем реальноговремени, а CTOS фирмы Unisys популярна вобласти банковского дела. Объектно-ориентированныйподход
Хотя технология микроядер изаложила основы модульных систем,способных развиваться регулярнымобразом, она не смогла в полной мереобеспечить возможности расширениясистем. В настоящее время этой целив наибольшей степени соответствуетобъектно-ориентированный подход,при котором каждый программныйкомпонент является функциональноизолированным от других.
Основным понятием этого подходаявляется «объект». Объект — это единица программ и данных,взаимодействующая с другимиобъектам посредством приема ипередачи сообщений. Объект можетбыть представлением как некоторыхконкретных вещей — прикладнойпрограммы или документа, так инекоторых абстракций — процесса,события.
Программы (функции) объектаопределяют перечень действий,которые могут быть выполнены надданными этого объекта.Объект-клиент может обратиться кдругому объекту, послав сообщение сзапросом на выполнение какой-либофункции объекта-сервера.
Объекты могут описывать сущности,которые они представляют, с разнойстепенью детализации. Дляобеспечения преемственности припереходе к более детальномуописанию разработчикампредлагается механизмнаследования свойств ужесуществующих объектов, то естьмеханизм, позволяющий порождатьболее конкретные объекты из болееобщих. Например, при наличииобъекта «текстовый документ»разработчик может легко создатьобъект «текстовый документ вформате Word 6.0», добавивсоответствующее свойство кбазовому объекту. Механизмнаследования позволяет создатьиерархию объектов, в которой каждыйобъект более низкого уровняприобретает все свойства своегопредка.
Внутренняя структура данныхобъекта скрыта от наблюдения.Нельзя произвольно изменять данныеобъекта. Для того, чтобы получитьданные из объекта или поместитьданные в объект, необходимовызывать соответствующиеобъектные функции. Это изолируетобъект от того кода, которыйиспользует его. Разработчик можетобращаться к функциям другихобъектов, или строить новые объектыпутем наследования свойств другихобъектов, ничего не зная о том, какони сконструированы. Это свойствоназывается инкапсуляцией.
Таким образом, объект предстаетдля внешнего мира в виде «черногоящика» с хорошо определенныминтерфейсом. С точки зренияразработчика, использующегообъект, пока внешняя реакцияобъекта остается без изменений, неимеют значения никакие измененияво внутренней реализации. Это даетвозможность легко заменять однуреализацию объекта другой,например, в случае смены аппаратныхсредств; при этом сложноепрограммное окружение, в которомнаходятся заменяемые объекты, непотребует никаких изменений.
С другой стороны, способностьобъектов представать в виде«черного ящика» позволяетупаковывать в них и представлять ввиде объектов уже существующиеприложения, ничего в них не изменяя.
Использованиеобъектно-ориентированного подходаособенно эффективно при созданииактивно развивающегосяпрограммного обеспечения,например, при разработкеприложений, предназначенных длявыполнения на разных аппаратныхплатформах.
Полностьюобъектно-ориентированныеоперационные системы оченьпривлекательны для системныхпрограммистов, так как, используяобъекты системного уровня,программисты смогут залезатьвглубь операционных систем дляприспособления их к своим нуждам,не нарушая целостность системы.
Но особенно большие перспективыимеет этот подход в реализациираспределенных вычислительныхсред. В то время, как сейчас разныепакеты, работающие в данный моментв сети, представляют собойстатически связанные наборыпрограмм, в будущем, сиспользованиемобъектно-ориентированного подхода,они могут превратиться в единуюсовокупность динамическисвязываемых объектов, где каждыйобъект оперативно устанавливает иразрывает связи с другимиобъектами для выполненияактуальных в данный момент задач.Приложения, созданные для такойсетевой среды, основанной наобъектах, могут выполняться,динамически обращаясь к множествуобъектов, независимо от ихместонахождения в сети инезависимо от их операционнойсреды.
Поскольку любоеобъектно-ориентированноеприложение представляет собойнабор объектов, разработчикужелательно иметь стандартныесредства для управления объектамии организации их взаимодействия.При использовании и разработкеобъектно-ориентированныхприложений в неоднородныхраспределенных средах, нужны такжесредства, упрощающие доступ кобъектам сети. При возникновениизапроса к какому-либо объектураспределенной среды, независимоот того, находится требуемый объектна том же компьютере или на одном изудаленных, прозрачным образомдолжен быть выполнен поиск объекта,передача ему сообщения, и возвратответа. Для обеспеченияпрозрачного обнаружения объектов,все они должны быть снабженыссылками, хранящимися в каталогах.Отсюда вытекает очень сложнаяпроблема организации службыкаталогов, позволяющейпрограммистам именовать и искатьобъекты в сети, которая, вообщеговоря, может быть разбросана повсему миру.
Однако, несмотря на упомянутыесложности и проблемы,объектно-ориентированный подходявляется одной из самыхперспективных тенденций вконструировании программногообеспечения.
Коммерческиеобъектно-ориентированные средства
Объектно-ориентированный подходк построению операционных систем,придающий порядок процессудобавления модульных расширений кнебольшому ядру был принят навооружение многими известнымифирмами, такими как Microsoft, Apple, IBM,Novell/USL (UNIX Systems Laboratories) и Sun Microsystems — все они развернули своиоперационные системы в этомнаправлении. Taligent, совместноепредприятие IBM и Apple, надеетсяопередить всех со своей от началадо конца объектно-ориентированнойоперационной системой. Темвременем Next поставляет Motorola- иIntel-версии NextStep, наиболеепродвинутойобъектно-ориентированнойоперационной системы из имеющихся.Хотя NextStep и не имеет объектнойориентированности сверху донизу,как это планируется в разработкахTaligent, но она доступна уже сегодня.
Одним из первых примененийобъектных систем для большинствапользователей станут основанные наобъектах прикладные программы. Кобъектно-ориентированнымтехнологиям этого уровня, ужеимеющимся сейчас или доступным вближайшем будущем относятся: Microsoft OLE (Object Linking and Embedding — связывание и внедрение объектов), стандарт OpenDoc от фирм Apple, IBM, WordPerfect, Novell и Borland, DSOM (Distributed System Object Model — объектная модель распределенных систем) фирмы IBM, PDO (Portable Distributed Objects — переносимые распределенные объекты) фирмы Next, каркасы (frameworks) фирмы Taligent, архитектура CORBA объединения OMG.
Средства OLE
Для пользователей Windowsобъектно-ориентированный подходпроявляется при работе спрограммами, использующимитехнологию OLE фирмы Microsoft. В первойверсии OLE, которая дебютировала вWindows 3.1, пользователи могливставлять объекты вдокументы-клиенты. Такие объектыустанавливали ссылку на данные (вслучае связывания) или содержалиданные (в случае внедрения) вформате, распознаваемомпрограммой-сервером. Для запускапрограммы-сервера пользователиделали двойной щелчок на объекте,посредством чего передавали данныесерверу для редактирования. OLE 2.0,доступная в настоящее время вкачестве расширения Windows 3.1,переопределяет документ-клиент какконтейнер. Когда пользовательщелкает дважды над объектом OLE 2.0,вставленным в документ-контейнер,он активизируется в том же самомместе. Представим, например, чтоконтейнером является документMicrosoft Word 6.0, а вставленный объектпредставляет собой набор ячеек вформате Excel 5.0. Когда вы щелкнетедважды над объектом электроннойтаблицы, меню и управляющиеэлементы Word как по волшебствупоменяются на меню Excel. Врезультате, пока объектэлектронной таблицы находится вфокусе, текстовый процессорстановится электронной таблицей.
Инфраструктура, требуемая дляобеспечения столь сложныхвзаимодействий объектов, настолькообширна, что Microsoft называет OLE 2.0«1/3 операционной системы».Хранение объектов, например,использует docfile, который вдействительности являетсяминиатюрной файловой системой,содержащейся внутри обычного файлаMS-DOS. Docfile имеет свои собственныевнутренние механизмы для семантикиподкаталогов, блокировок итранзакций (т.е. фиксации-отката).
Наиболее заметный недостаток OLE — отсутствие сетевой поддержки, и этобудет иметь наивысший приоритетпри разработке будущих версий OLE.Следующая основная итерация OLEпоявится в распределенной,объектной версии Windows, называемойCairo (Каир), ожидаемой в 1995 году.
Стандарт OpenDoc
Apple, совместно с WordPerfect, Novell, Sun, Xerox,Oracle, IBM и Taligent, известными вместе какComponent Integration Laboratory (Лаборатория пообъединению компонентов), такжезанимается архитектуройобъектно-ориентированныхсоставных документов, называемойOpenDoc. Создаваемый для работы наразных платформах, этот проектзначительно отстает по степениготовности от OLE 2.0.
Ключевыми технологиями OpenDocявляются механизм хранения Бенто(названный так в честь японскойтарелки с отделениями для разнойпищи), технология сценариев (scripting),позаимствованная в значительнойстепени из AppleSript, и SOM фирмы IBM. ВБенто-документе каждый объектимеет постоянный идентификатор,перемещающийся вместе с ним отсистемы к системе. Хранение нетолько является транзакционным,как в OLE, но и позволяет держать иотслеживать многочисленныередакции каждого объекта. Еслиимеется несколько редакцийдокумента, то реально хранитьсябудут только изменения от однойредакции к другой. Верхняя границачисла сохраняемых редакций будетопределяться пользователем.
Команда Apple планирует сделать OpenDocсовместимым с Microsoft OLE. Если планзавершится успехом, система OpenDocсможет окружать объекты OLE слоемпрограмм трансляции сообщений.Контейнер OpenDoc будет видетьвстроенный объект OLE как объектOpenDoc, а объект OLE будет представлятьсвой контейнер, как контейнер OLE.Утверждается, что будет допустиматакже и обратная трансляция поэтому сценарию, когда объекты OpenDocфункционируют в контейнерах OLE.Слой трансляции разрабатываетсяWordPerfect при помощи Borland, Claris, Lotus идругих.
В основе OLE и OpenDoc лежат двесоперничающие объектные модели:Microsoft COM (Component Object Model — компонентнаяобъектная модель) и IBM SOM. Каждаяопределяет протоколы, используемыеобъектами для взаимодействия другс другом. Основное их различиезаключается в том, что SOM нейтральнак языкам программирования иподдерживает наследование, тогдакак COM ориентирована на С ++ и вместомеханизма наследования используетальтернативный механизм, которыйMicrosoft называет агрегацией.
Семейство CORBA
Hewlett-Packard, Sun Microsystems и DECэкспериментируют с объектами ужемного лет. Теперь эти компании имного других объединились вместе,основав промышленную коалицию подназванием OMG (Object Management Group),разрабатывающую стандарты дляобмена объектами. OMG CORBA (Common Object RequestBroker Architecture — Общая архитектурапосредника обработки объектныхзапросов) закладывает фундаментраспределенных вычислений спереносимыми объектами. CORBA задаетспособ поиска объектами другихобъектов и вызова их методов. SOMсогласуется с CORBA. Если выпользуетесь DSOM под OS/2, вы сможетевызывать CORBA-совместимые объекты,работающие на HP, Sun и другихархитектурах. Означает ли этовозможность редактировать объектOpenDoc, сделанный на Macintosh, вдокументе-контейнере на RISC-рабочейстанции? Вероятно, нет. CORBA можетгарантировать только механизмнижнего уровня, посредствомкоторого одни объекты вызываютдругие. Для успешноговзаимодействия требуется такжепонимание сообщений друг друга. Множественныеприкладные среды
В то время как некоторые идеи(например,объектно-ориентированный подход)непосредственно касаются толькоразработчиков и лишь косвенновлияют на конечного пользователя,концепция множественныхприкладных сред приноситпользователю долгожданнуювозможность выполнять на своей ОСпрограммы, написанные для другихоперационных систем и другихпроцессоров.
И сейчас дополнительноепрограммное обеспечение позволяетпользователям некоторых ОСзапускать чужие программы(например, Mac и UNIX позволяютвыполнять программы для DOS и Windows).Но в зарождающемся поколенииоперационных систем средства длявыполнения чужих программстановятся стандартной частьюсистемы. Выбор операционнойсистемы больше не будет сильноограничивать выбор прикладныхпрограмм. Хотя столкновениепользовательских интерфейсовпрограмм для Mac, Windows и UNIX на одном итом же экране и заставитпользователя немного потрудиться,но все равно, множественныеприкладные среды операционныхсистем скоро станут такими жестандартными, как мыши и меню.
Множественные прикладные средыобеспечивают совместимость даннойОС с приложениями, написанными длядругих ОС и процессоров, надвоичном уровне, а не на уровнеисходных текстов. Для пользователя,купившего в свое время пакет(например, Lotus 1-2-3) для MS DOS, важно,чтобы он мог запускать этотполюбившийся ему пакет безкаких-либо изменений и на своейновой машине, построенной,например, на RISC-процессоре, иработающей под управлением,например, Windows NT.
При реализации множественныхприкладных сред разработчикисталкиваются с противоречивымитребованиями. С одной стороны,задачей каждой прикладной средыявляется выполнение программы повозможности так, как если бы онавыполнялась на «родной» ОС. Нопотребности этих программ могутвходить в конфликт с конструкциейсовременной операционной системы.Специализированные драйверыустройств могут противоречитьтребованиям безопасности. Могутконфликтовать схемы управленияпамятью и оконные системы. Чистоэкономические вопросы (например,стоимость лицензирования программи угроза судебного преследования)также могут повлиять на дизайнчужих прикладных сред. Но самойбольшой потенциальной проблемойявляется производительность — прикладная среда должна выполнятьпрограммы с приемлемой скоростью.