Машинная архитектура высокого уровня

Истинная независимость от аппаратуры может быть достигнута, если вместо определения отдельных API для разных специфических приложений (что имеет место в случае такой API-ориентированной архитектуры как Single Unix Specification), будет формально определен общий интерфейс для всех приложений. Более того, если в такой интерфейс заложены возможности расширения, то в любое время для достижения переносимости приложений к нему могут быть добавлены API Single UNIX Specification. Именно такой подход лежит в основе архитектуры AS/400, которая определяет законченный набор API для всех приложений и не позволяет последним обходить API.

Независимый от технологии машинный интерфейс (Technology-Independent Machine Interface), который часто называют просто MI²⁾, представляет собой формальное определение интерфейса для всех приложений и большинства компонентов операционной системы. Аппаратура, а также все программное обеспечение операционной системы, которому должны быть доступны подробности аппаратной реализации, располагаются ниже границы MI.

Чтобы понять, как достигается независимость программного обеспечения от изменений в аппаратуре, обусловленных технологическим прогрессом, необходимо кратко рассмотреть, как работает компилятор. Ранее было сказано, что в традиционной процессороориентированной системе компилятор генерирует двоичный машинный код непосредственно из исходного текста, что иногда требует дополнительного шага ассемблирования. В AS/400 компилятор генерирует из исходного текста код MI, который оформляется в виде так называемого шаблона программы. На втором этапе транслятор AS/400 генерирует двоичный код по содержимому шаблона программы. Фактически, этот транслятор выполняет те же действия, что и заключительный проход современного компилятора. Затем, если явно не запрошено его удаление, шаблон программы сохраняется вместе с двоичным кодом в программном объекте. Такая программа называется отслеживаемой (observable). При переносе программного объекта на новую аппаратную базу, например, на 64-разрядный PowerPC, другой транслятор, созданный для новой аппаратуры, перетранслирует шаблон программы в новый двоичный код. Изменений в исходном коде при этом не требуется — чем и достигается независимость от технологии. Более подробное рассмотрение этого вопроса мы отложим до лекции 4.

Значимость такой независимости очевидна для пользователей и ISV. Переход на 64-разрядную технологию RISC дает не только более мощный процессор — операционная система и все приложения сразу же становятся 64-разрядными. Для того чтобы воспользоваться преимуществами 64-разрядного оборудования не нужно ничего переписывать. В один день RISC-системы AS/400 получают 64-разрядную операционную систему и десятки тысяч 64-разрядных приложений.

Архитектура AS/400 заслужила титул "расширенной архитектуры приложений" (Advanced Application Architecture), так как предоставляет возможности, которых многие другие вычислительные системы все еще пытаются достичь с помощью API-ориентированного подхода. AS/400 уже сейчас независима от нижележащей технологии. Хотя независимость от аппаратуры важна, но не менее важна и независимость от деталей операционной системы. В AS/400 достигнуто и это. Термин "расширенная архитектура" подразумевает, что к ней могут быть добавлены вновь определяемые API других операционных систем, что обеспечивает еще большую переносимость приложений.

И это тоже есть!

"Это там есть; все там есть!", — восклицает телевизионная реклама известного соуса для спагетти. Вместо того, чтобы покупать ингредиенты и делать соус самому — убеждает голос за кадром — лучше просто купить бутылку этого соуса и быть уверенным, что все качественные и свежие составляющие, которые Вы использовали бы, уже там. Гленн Ван Беншотен (Glenn Van Benschoten), системный менеджер AS/400, любит использовать аналогию с соусом для спагетти для описания интегрированной сущности AS/400. Все, что Вы можете пожелать для своего компьютера, уже там есть.

AS/400 — это интегрированная система, и эта характеристика отличает ее от большинства других. Для вычислительной системы интеграция означает, что различные части работают вместе как одно целое. Для заказчика это означает, что систему легче устанавливать, сопровождать и использовать, что снижает накладные расходы в бизнесе.

Если бы Вы спросили разработчика из подразделения в Рочестере, в чем причина успеха AS/400, то вероятно получили бы ответ, что здесь знают, как создавать наилучшие коммерческие многопользовательские системы. Если "нажать" посильнее, Ваш собеседник, вероятно, начнет сравнивать конкретные возможности, такие как база данных или структура защиты, с возможностями других систем. На мой взгляд, главное не в этом. Да, у AS/400 мощная база данных и надежная система защиты, но этим обладают и другие системы. Отличительная черта AS/400, которую многие наши разработчики считают само собой разумеющейся, — то, что все компоненты спроектированы, чтобы работать вместе. Система AS/400 — это больше, чем просто сумма составных частей.

Если задать тот же вопрос ISV, то он, вероятно, скажет, что для AS/400 проще, чем для какой-либо другой платформы, разрабатывать и сопровождать приложения. ISV, имеющие свои приложения как для AS/400, так и для других платформ, например Unix, часто указывают на разницу в численности людей, работающих для одной или другой платформы. Обычно, для разработки приложений для AS/400 требуется гораздо меньше людей, и это также — заслуга интеграции. Гарантируя, что новая добавленная функция будет гладко работать со всеми остальными частями системы, мы сокращаем расходы на разработку для AS/400. Все системы, созданные в Рочестере до AS/400 включительно, решены интегрировано, и именно в этом секрет их успеха.

Но если даже наши собственные разработчики порой забывают об этом факторе, то благодаря чему AS/400 остается интегрированной системой? Ответ — MI. MI делает для обеспечения интеграции две вещи. Во-первых, он предоставляет общий интерфейс для всех приложений и функций операционной системы, реализованных поверх него, благодаря чему всем приходится использовать систему одинаковым образом. Во-вторых, MI — функционально законченный интерфейс. Так как обойти его невозможно, MI предоставляет все функции, которые могут потребоваться прикладной или системной программе. Если какая-либо нужная функция отсутствует, то программа не будет работать на AS/400. MI также обладает большими возможностями расширения, что позволяет включать в него новые функции по мере надобности.

Прежде чем кто-нибудь укажет на то, что другие системы Рочестера, такие как System/36, добивались интеграции без машинного интерфейса высокого уровня, я должен отметить, что MI обеспечивает и интеграцию, и аппаратную независимость. У System/36 был эквивалент машинного интерфейса для большинства системных функций, но не для приложений. В этой системе два отдельных процессора выполняли: один — пользовательские приложения, а другой — некоторые функции операционной системы. Доступ к этим функциям на втором процессоре был возможен только посредством строго определенного интерфейса между двумя процессорами. Данный интерфейс, подобно MI, гарантировал полноту набора функций и возможность их совместной работы. Приложения, однако, по-прежнему зависели от аппаратуры. По этой причине (как мы увидим в лекции 3) для выполнения приложений System/36 на другой аппаратуре требовался эмулятор.

Отрицательная сторона интеграции — отсутствие гибкости. В интегрированных решениях обычно имеет место подход "все или ничего". Клиент не может выбрать ОС одного производителя, базу данных — другого и пакет защиты — третьего, так как все они не предназначены для работы в интегрированной системе.

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

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

В общем, ситуация напоминает мне ту, в которой я оказался не так давно при покупке и установке новой аудиовидеосистемы. Каждый из четырех ее компонентов имел собственный пульт дистанционного управления. Поскольку все компоненты произведены одной фирмой, продавец заверил меня, что каждый пульт универсален, то есть может управлять всеми частями комплекса, а следовательно для системы в целом нужен всего один пульт. В действительности оказалось, что с помощью одного пульта можно управлять лишь некоторыми функциями каждого компонента, но не всей системой в целом: для этого надо использовать все четыре пульта. Кроме того, "пользовательские интерфейсы" пультов разные, кнопки для выполнения одной и той же функции находятся на них в разных местах и часто имеют разную форму и размер. Даже названия некоторых идентичных функций различаются. Точно также многим пользователям компьютеров приходится использовать несколько "пультов управления" при эксплуатации своих вычислительных систем. И им, и мне больше подошла бы интегрированная система.

Объекты

Объекты предоставляют средства управления и защиты системных ресурсов AS/400. Правила именования и адресации практически всех элементов системы привязаны к объектам. Эта лекция будет посвящена объектам.

Сетевые вычисления и Интернет сделали тему объектных технологий бестселлером компьютерных новостей. Распространение таких языков программирования, как Java и С++, заставляет разработчиков приложений изменить свое отношение к традициям и признать преимущества новых объектноориентированных языков.

Подобно другим технологиям, которые мы считаем новыми, объекты используются в программировании уже более 30 лет. Впервые они появились в конце 60-х годов в языках типа Simula 67, применявшихся для программ моделирования. Современные языки программирования, такие как Java, C++ и Smalltalk — прямые потомки Simula 67. Программы моделирования имитируют поведение объектов реального мира. Аналогично, прикладные программы для бизнеса, содержащие объекты и операции над ними, моделируют реальные деловые отношения.

ОС работают с аппаратными и программными объектами, такими как устройства ввода-вывода и программы. Использование объектов в ОС выглядит совершенно естественным. О создании объектноориентированной ОС говорят многие фирмы, такие как Microsoft, Apple, Novell/USL (UNIX Systems Laboratory) и Sun Microsystems, однако, лишь немногие из них смогли реализовать свои планы. Одна из таких фирм — Next, уже поставляющая на рынок объектноориентированную ОС под названием NextStep.

Есть, конечно, и другая объектноориентированная ОС. С момента появления System/38 мы строим ОС (CPF и OS/400) по объектноориентированной модели¹⁾. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в лекции 4, MI состоит из двух частей: команд и объектов. В этой лекции мы рассмотрим использование объектов в AS/400.

Иногда говорят, что AS/400 это не объектноориентированная система, а система на основе объектов (objectbased). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектноориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследование²⁾. Как уже вкратце упоминалось в лекции 3, наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/400 не просто использует или включает объекты, — они являются фундаментальной частью ее архитектуры.

В упрощенном виде объект — это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.

Еще одно достоинство объектов — целостность. Оригинальная System/3 была байтовой машиной (то есть все в ней располагалось на границе байта), а ее команды содержали однобайтовый код операции. Они занимали несколько последовательных байтов памяти, но никакого обязательного выравнивания команд не было. Более того, все разряды кода были задействованы для задания типа операции и местоположения операндов. Практически любая комбинация разрядов в байте могла быть интерпретирована как допустимый код операции System/3.

Это вызывало проблему, если в программе непреднамеренно происходил переход в область данных: процессор мог продолжать выбирать байты данных и интерпретировать их как команды. Такая программа могла исполняться долгое время, сея хаос внутри системы. Ликвидировать последствия таких ошибок было весьма сложно.

В этом плане System/3, ничем не отличалась от большинства других вычислительных систем того времени. Например, в обычной системе цепочка байтов может быть интерпретирована, практически, как угодно. Можно взять байты из одной части программы и перемножить их с байтами из другой ее части. Процессор "не волнует", имеет ли смысл такая операция. Он работает с байтами, а не с тем, что они представляют.

Итак, мы были очень обеспокоены проблемами целостности, и сделали все, что бы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как "Создать объект", применимы ко всем объектам, другие — работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.

На эту проблему можно взглянуть и с другой стороны. В большинстве ОС, все, что находится в постоянной памяти, считается файлом (в MSDOS или MVS файлом называют набор данных). Файлы могут иметь различное назначение, но такая классификация определяется лишь по соглашению. Вы можете читать объект-программу так, как если бы это был файл. В OS/400 это невозможно (как и создать вирус, по крайней мере, в слое над MI), так как термин "файл" применим лишь к небольшому числу типов объектов, и программа определенно файлом не является. Кстати, с этим связаны некоторые неудобства, присутствовавшие в System/38, где значительная часть информации об объектах была недоступна программам. COMMON (группа пользователей AS/400) многократно просила включить во все команды отображения, такие как, например, "DSPOUTQ" ("Display Output Queue"), "DSPJOBQ" ("Display Job Queue"), опцию генерации выходного файла, чтобы информация, хранящаяся внутри объектов, могла быть считана программно. В конце концов, мы добавили такую возможность в некоторые команды, которые первоначально ей не обладали (а в "DSPOUTQ" и "DSPJOBQ" ее нет и сейчас). Но исчерпывающим ответом на эти запросы было создание API, позволяющих поместить информацию об объектах и системе в объект, известный как пользовательское пространство. Этот объект программы могут читать быстрее, чем файлы базы данных.

Имена объектов

В System/38 объекты были как в ОС, так и в MI. Определением этих объектов и выбором имен для них занимались две разные группы. Одна разрабатывала объекты CPF, (которая в AS/400 была переименована в OS/400³⁾), другая — разрабатывала набор команд и системные объекты MI.

Хорошо, что иногда между объектом OS/400 и объектом MI соотношение один к одному, тогда это тот же самый объект. Все усложняется, когда это разные объекты. Все объекты OS/400 состоят из одного или нескольких системных объектов MI. Другими словами, типы объектов OS/400 и типы системных объектов MI соотносятся как один к одному или как один ко многим, но никогда как многие к одному или многие ко многим.

Пример, иллюстрирующий это положение, мы рассмотрим в следующем разделе. А теперь, прежде чем идти дальше, я должен внести ясность еще в одну область.

Иногда, объекты OS/400 и системные объекты MI, даже при соотношении между ними один к одному, могут называться поразному. Например, в OS/400 есть объект "библиотека", в MI эквивалентный объект называется "контекст". Как это могло получиться? Ответ восходит ко времени создания System/38 двумя разными группами проектировщиков с разными подходами к выбору названий.

Один подход таков: коль Вы создаете новую систему — то все надо переименовать, и пусть пользователи, видя новые названия вдумаются в новую структуру. По этой логике, если Вы собираетесь реализовать библиотеку и назвали ее библиотекой, то кто-нибудь обязательно скажет: "Я знаю, что такое библиотека; я уже работал с системой, где есть библиотеки". Между тем, библиотека в другой системе может полностью отличаться от Вашей. Если же дать библиотеке другое название, например "контекст", то никто не сможет априори строить о ней какие-либо предположения. Данный подход к именам защищал Гленн Хенри — менеджер программирования System/38 и, следуя подобным взглядам, группа, разрабатывавшая системные объекты MI, породила некоторые весьма странные названия.

Названия же для объектов ОС выбирала другая группа, предпочитавшая под ход Томаса Эдисона (Thomas Edison): лучше даже не вполне подходящее, но уже знакомое покупателям имя. Когда Эдисон продвигал идеи использования электроэнергии, он решил выбирать названия, знакомые каждому, использующему природный газ. Он говорил, что к дому подводятся электрические магистрали (main), подобно газовым или водопроводным магистралям, хотя main — это труба или канал, а электроны, обычно, попадают в дом не по трубе. Он также называл нагревательный элемент кухонной плиты электрической горелкой, чтобы электрическая плита казалась чем-то знакомым людям, имевшим дело с газовыми горелками (скажем честно — электричество в нагревающем элементе не "горит"). Наша группа разработчиков ОС понравилась бы Эдисону.