Основы AS/400

Расширенная архитектура приложений

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

Общеизвестно, что у AS/400 прогрессивная, самая адаптируемая архитектура в мире, и что новые технологии не повлияют негативно на бизнес заказчиков этой системы. Да, это правда. Пользователям AS/400 не требуется «подгонять» свои прикладные программы под новые технологии. Однако, зачастую сами клиенты не понимают (или не хотят понимать) как работает система. Работает — и ладно!

Недавно архитектура AS/400 снова оказалась в центре внимания. AS/400 стала первой и единственной в мире системой, завершившей переход к 64-разрядным вычислениям. В новой модели был использован тип архитектуры процессора с сокращенным набором команд — RISC (reduced instruction set computer). Для сравнения: процессоры, использовавшиеся в исходной AS/400, а также другие популярные процессоры, такие как Intel Pentium или Intel Pentium Pro, используют архитектуру со сложным набором команд — CISC (complex instruction set computer). Главное достоинство RISC-архитектуры — более простые команды, чем у CISC. Это позволяет создавать процессоры, отличающиеся поразительной быстротой вычислений и за приемлемую цену. Последние версии RISC-процессоров всех производителей — 64-разрядные.

Проектирование и создание такой аппаратуры — не самая сложная проблема компьютерной индустрии. А вот как предоставить существующему программному обеспечению (ПО) возможность воспользоваться преимуществами новой аппаратуры? AS/400 — единственная система, где эта проблема решена. Все ее приложения используют 64-разрядные вычисления в полной мере.

Никакая другая система такими возможностями не обладает. Когда другие производители компьютеров переходили с CISC- на RISC-процессоры, это вызывало серьезные проблемы у их заказчиков и независимых производителей програмно-го обеспечения ISV (Independent Software Vendor), которым приходилось переписывать некоторые прикладные программы или их фрагменты. Так случилось, например, когда фирма Hewlett Packard объявила о своей архитектуре PA (Precision Architecture), или когда Digital Equipment Corporation (Digital) представила архитектуру Alpha.

Чтобы лучше понять масштаб проблемы, остановимся подробнее на попытке перехода на RISC, предпринятой фирмой Digital. По собственной оценке Digital перевод имеющегося парка на архитектуру Alpha вызовет необходимость переписать от 15 до 20 процентов старого кода приложений, предназначенных для архитектуры VAX. Любому заказчику или ISV такая модификация влетит в копеечку.

Архитектура AS/400, напротив, защищает пользователей системы и ISV от этих проблем при переходе на новые 64-разрядные RISC-процессоры. Существующие приложения сразу же в полной мере используют новые возможности аппаратуры.

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

Архитектура компьютера

Витрувий, римский архитектор I столетия нашей эры, определял архитектуру как акт проектирования структуры, обладающей полезностью, прочностью и способностью восхищать. Это и многое другое — общие характеристики как для архитектуры зданий, так и для архитектуры компьютеров.

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

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

С точки зрения программиста

В 1970 году С. С. Хассон (S. S. Husson) определил термин «архитектура компьютера» как «характеристики (вычислительной) системы с точки зрения программиста»[ 5 ]. Архитектура включает в себя набор команд, типы данных, операции ввода-вывода и другие характеристики. Иногда эти компоненты рассматриваются по отдельности, и тогда говорят об архитектуре наборов команд и архитектуре ввода-вывода. Архитектура в целом включает в себя все, что нужно знать программисту для создания корректно работающих программ.

С точки зрения аппаратуры у компьютера имеется пять основных компонентов: ввод, вывод, память, тракт данных (datapath) и устройство управления. Два последних компонента часто объединяют и называют процессором. Архитектура компьютера определяет, какие операции могут выполнять эти компоненты. Процессор выбирает данные и команды из памяти. Аппаратура ввода записывает данные в память, а аппаратура вывода — считывает из нее. Управляющая аппаратура генерирует сигналы, управляющие трактом данных, памятью, вводом и выводом.

Иногда процессор называют ЦПУ — центральным процессорным устройством CPU (central processing unit). В последнее время этот термин используется реже, так как современные технологии позволяют упаковать целый процессор в одну микросхему. Процессор, выполненный на одной микросхеме, обычно называют микропроцессором. Достаточно часто термины «ЦПУ», «процессор» и «микропроцессор» используют как эквивалентные. Однако, следует помнить, что не всякий процессор умещается на одной микросхеме — их может потребоваться несколько.

Если два компьютера могут выполнять один и тот же набор команд, то говорят, что у них одинаковая архитектура набора команд. Одна и та же архитектура может быть реализована по-разному. Так, например, архитектура Intel x86[ 6 ], применяемая во многих ПК, используется целым семейством микропроцессоров, созданных с помощью разных технологий и имеющих разную производительность. То есть конкретная технология, использованная при создании компьютера, не есть часть его архитектуры.

Уровни абстракции

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

На самом нижнем уровне — электронных схем — компьютер очень прост. Электронная схема понимает только две команды: включено и выключено, символически обозначаемые при помощи цифр 1 и 0. На данном уровне общение с машиной идет с помощью цепочек нулей и единиц. Команда — это понятный процессору набор двоичных цифр или битов (разрядов). Таким образом, команда представляет собой просто число в двоичной системе счисления или двоичное число. Компьютеры называются цифровыми, потому что на машинном языке для обозначения как команд, так и данных используются цифры.

Когда-то давно, программисты «общались» с компьютерами на языке двоичных чисел. Это не слишком удобно, поэтому был изобретен более высокий уровень абстракции — язык ассемблера, представляющий собой символическую форму двоичного языка компьютера. Ассемблером называется программа, транслирующая символическое представление команд в двоичную форму.

Для большинства программистов язык ассемблера — также не вполне естественный, поэтому был создан еще более высокий уровень абстракции — язык программирования высокого уровня (ЯВУ). В настоящее время насчитываются сотни таких языков; наиболее известные из них — Basic, C, C++, Cobol и RPG. Программа, принимающая на входе текст на одном из языков высокого уровня и транслирующая его в операторы языка ассемблера, называется компилятором.

Иллюстрация многоуровневой абстракции — написание программы на языке высокого уровня. Компилятор выполняет преобразование программы на ЯВУ в язык ассемблера, который затем переводит свои команды в двоичный код, понятный процессору. Замечу, что некоторые компиляторы генерируют команды непосредственно на машинном языке, минуя уровень ассемблера.

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

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

Похожа на эмуляцию интерпретация программ. Программа-интерпретатор выбирает инструкции по одной и исполняет эквивалентную им последовательность команд более низкого уровня. Некоторые из новейших ЯВУ, используемых в распределенных вычислениях, например Java, разработаны так, чтобы их было легко интерпретировать. Большинство командных языков также интерпретируемы. Введите «dir» в командной строке DOS на любом ПК и на экране появится содержимое каталога. Если после этого нажать клавишу Enter, интерпретатор командной строки DOS считает введенную команду, а затем выполнит последовательность инструкций, необходимых для ее выполнения. Такой интерпретатор команд есть в большинстве операционных систем. В микропрограммируемой машине интерпретация обычно поддерживается специальным оборудованием. Микропрограмма для различения такой аппаратной формы интерпретации называется эмулятором.

Обычно архитектура набора команд вычислительной системы рассматривается как интерфейс между аппаратурой и программным обеспечением самого нижнего уровня. В те времена, когда Хассон сформулировал упоминавшееся выше определение архитектуры компьютера, программирование еще не использовало ЯВУ. Сегодня, более подходящим определением этого понятия было бы «характеристики системы с точки зрения компилятора», так как из нынешних программистов лишь немногие имеют дело с программами в машинных кодах.

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

Создание программ

Программное обеспечение любой вычислительной системы можно условно разделить на два типа: системное и прикладное. Примеры системного программного обеспечения — операционные системы, ассемблеры и компиляторы. Прикладное же программное обеспечение обычно предназначается непосредственно для пользователей и решает конкретные задачи.

Ранее считалось, что доступ к архитектуре самого нижнего уровня посредством ассемблера необходим как системному, так и прикладному программисту. В пользу этого суждения приводилось множество аргументов: большинство программ имели доступ к крайне незначительному объему памяти, процессоры были медленными и дорогими, а компиляторы с языков высокого уровня — не слишком хорошими. Когда нужно было «выжать последний грамм» для повышения производительности компьютера, «настоящие» программисты использовали язык ассемблера.

Теперь же появилось много приверженцев мнения, что программирование на языке ассемблера — реликт прошлого. Но это не так. Большинство используемых ныне операционных систем (не только старых, чьи корни которых восходят к 60-м и началу 70-х годов, но и более современных) включают в себя большие объемы кода на ассемблере. Таковы, например, операционные системы для ПК: Windows 95 фирмы Microsoft написана по большей части на языке ассемблера Intel.

Первые процессоры для ПК имели достаточно ограниченные возможности. Максимальный размер памяти был равен 64 килобайтам. (Один килобайт равен 210 или 1024 байтам. Байт — это 8-разрядная ячейка памяти, в которой может храниться символ или цифра). Память стоила настолько дорого, что операционные системы могли занимать не более 4 килобайт. Язык ассемблера позволял программистам максимально сокращать размер кода. В результате на нем написан такой большой объем операционных систем, что даже когда размер доступной памяти увеличился благодаря удешевлению технологии, возвращаться назад и переписывать оригинальный код оказалось непрактичным.

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

В качестве примера такой ситуации рассмотрим компьютер, имеющий восемь регистров. Регистр — часть тракта данных процессора. Это быстродействующая область памяти, куда помещаются данные и адреса на время их использования процессором. Основное назначение регистров — повышение производительности работы программ. Предположим, что ширина каждого регистра — 16 разрядов, и что программист может помещать данные в регистры и выбирать их оттуда в любой момент по своему усмотрению. Число регистров и их характеристики программист видит из ассемблера. Таким образом, каждая программа для данного компьютера, написанная на этом языке, будет «знать» о восьми регистрах и зависеть от них.

Теперь предположим, что технологический прогресс позволил конструкторам увеличить количество регистров до 16 и сделать их 32-разрядными, причем стоит все это столько же, сколько и оригинальные 8 регистров меньшего размера. Зададимся вопросом: «Как это повлияет на программы, написанные для старого компьютера?». Ответ зависит от того, каким образом были сделаны изменения, и сколь хорошо первоначальная архитектура была спланирована для расширения в будущем.

Допустим, что в старой архитектуре предполагалось расширение до 16 регистров. В каждой команде было зарезервировано достаточно места для адресации 16 регистров, хотя первоначально были реализованы только 8. Для каждой команды, использующей регистры, в данном случае понадобились бы 4-разрядные поля, так как 4 бита позволяют закодировать 16 различных комбинаций нулей и единиц. На новом оборудовании старые программы могут выполняться без изменений. При этом они по-прежнему будут использовать только 8 регистров, новые же программы смогут воспользоваться всеми 16-ю.

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

Одна из многих архитектур, неспособных увеличить число пользовательских регистров, — Intel Pentium Pro. Она использует то же количество регистров, что и ее предшественник Intel 386. Хотя увеличение числа регистров дало бы Pentium Pro преимущества, но затраты на переписывание существующих ассемблерных программ слишком велики.

Вообще, увеличение размера регистров с 16 до 32 разрядов оказывает меньшее влияние, чем изменение их количества. Если увеличился только размер, то старые программы будут по-прежнему работать, но использовать лишь 16 из 32 разрядов новых регистров. Данная информация внедрена в логику программы, и ее трудно изменить[ 7 ].

И подобных примеров, когда широко применяемые программы не способны использовать все ресурсы оборудования, — несметное множество. Процессор Intel 386, появившийся еще в 1985 году, имел 32-разрядный дизайн, то есть размер его аппаратных регистров был равен 32 битам. С того времени все процессоры Intel, включая 486, Pentium, Pentium II и Pentium Pro — 32-разрядные. Однако и большинство программ для ПК, использующих эти процессоры, и операционная система DOS были созданы в те времена, когда был доступен только 16-разрядный процессор Intel 286. Даже операционная система Windows 95 написана в основном на 16-разрядном ассемблере. На переписывание прикладных и системных программ ПК под 32-разрядную аппаратуру ушло уже 12 лет, и процесс все еще не завершен.

Эта проблема не ограничивается только индустрией ПК. Прогресс аппаратных технологий поднял планку еще выше: большинство новых процессоров будут 64-разрядными. Чтобы воспользоваться этим более мощным оборудованием, большинство современных 32-разрядных операционных систем и 32-разрядных прикладных программ должны быть переписаны. А это опять долгие годы работы.

В рассмотренных выше примерах модификации аппаратуры состояли в изменении размера и числа регистров процессора. Учтите, что аналогичное влияние на программное обеспечение, написанное на ассемблере, могут оказать и изменения в структуре адресации процессора или в самом наборе команд.

Основная цель программирования только на языках высокого уровня — минимизировать изменения в программах, вызываемые подобными модификациями аппаратуры. К сожалению, в системном программном обеспечении явно наблюдается тенденция перехода на языки, подобные С и С++. Использование С позволяет повысить переносимость системного программного обеспечения, так как компиляторы для этого языка есть на многих аппаратных платформах, но не устраняет все сложности, связанные с изменениями в оборудовании. Некоторые аппаратные характеристики, например разрядность процессора, видимы программисту на С. Такая возможность доступа к внутренним характеристикам привлекательна для системных программистов и объясняет популярность С. Это язык называют «современным ассемблером». В обычной вычислительной системе переход, например, с 32-разрядного процессора на 64-разрядный по-прежнему будет требовать изменений в программе на С. А это снижает переносимость С-программ.

Для иллюстрации рассмотрим опыт Digital. Последние несколько лет эта фирма продает свои машины с 64-разрядным процессором Alpha. Однако две основные операционные системы, используемые на этих компьютерах — Open VMS самой Digital и Windows NT фирмы Microsoft — все еще 32-разрядные, хотя и написаны, в основном, на С. Приложения для этих операционных систем, также 32-разрядные. Простая перекомпиляция здесь не поможет. Чтобы задействовать все ресурсы процессора, и операционные системы, и приложения надо полностью переписать, и это займет много лет.

HP также загнала покупателей своей HP 9000 в трясину переделок. Сейчас HP продает 64-разрядные версии своих процессоров PA-RISC. Чтобы воспользоваться преимуществами новых аппаратных средств, заказчикам HP придется ждать появления новой 64-разрядной ОС, и затем переписывать свои приложения. На это потребуется столько времени, что уже теперь, задолго до того, как переделка ПО будет завершена (см. главу 12), есть признаки того, что HP может отказаться от дальнейшей разработки HP 9000.

Секрет успешного перехода к 64-разрядным вычислениям на AS/400, в то время как никому больше это не удалось, кроется в ее архитектуре.

Классификация архитектур

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

Процессоро-ориентированная архитектура

Подавляющее большинство используемых ныне компьютерных архитектур основаны на традиционном подходе, открывающем программисту аппаратный интерфейс. Такие архитектуры называются процессоро-ориентированными (processor-centric) потому, что аппаратный интерфейс в них видим прикладным программам и используется последними непосредственно. Примеры процессоро-ориентированных архитектур — PA фирмы HP и Alpha фирмы Digital.

API-ориентированные архитектуры

Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API[ 8 ] (application programming interface). Такие API-ориентированные архитектурыустанавливают коммуникационный барьер — интерфейс, который используется всем прикладными программами для доступа к сервисам операционной системы и изолирует их от аппаратных и программных деталей.

Операционная система — это набор программ, управляющих системными ресурсами и служащих фундаментом для написания прикладных программ. Часто таким фундаментом становятся API. Существуют различные формы реализации API. Это может быть вызов или команда, запрашивающая у операционной системы согласие на выполнение некоторых действий. Хорошо известный пример API — функция операционной системы, вызываемая прикладной программой для выполнения операции ввода-вывода, такой как чтение с диска. Очевидно, что прикладной программе незачем «знать» подробности внутренней работы ввода-вывода. Программы операционной системы, выполняющие функции ввода-вывода и часто называемые подсистемами ввода-вывода, изолируют приложения от деталей аппаратной и программной реализации. Приложения, использующие для выполнения ввода-вывода только соответствующие API, не зависят от каких-либо изменений в структуре ввода-вывода на нижних уровнях.

Дополнительное преимущество дает реализация разными производителями одного и того же набора API. В этом случае приложения легко переносить с одной системы на другую. Один из наиболее известных стандартных наборов API — POSIX. POSIX — сокращение, неформально расшифровываемое как «переносимый интерфейс операционной системы базирующейся на Unix» (portable operating system interface based on Unix) — это набор международных стандартов для интерфейсов Unix-подоб-ных операционных систем. Правительственные и неправительственные организации поощряют реализацию производителями Unix-подобных операционных систем данных стандартов, как обеспечивающую переносимость приложений с одной системы на другую.

Общая проблема стандартов типа POSIX состоит в том, что они никогда не становятся законченными, и стадия определения такого стандарта занимает многие годы. В такой ситуации разработчики приложений часто берут дело в свои руки. В 1993 году группа разработчиков приложений для Unix и производителей Unix-подобных операционных систем решила определить свой собственный набор API. Они не могли ждать, пока спецификация POSIX «созреет» до такой степени, чтобы ее можно было использовать. Кроме того, ясно, что когда спецификация POSIX будет, наконец, полностью завершена, все приложения придется переписывать под новый стандарт.

Вместо этого, упомянутая группа разработчиков выделила все API, которые используются в настоящее время наиболее популярными приложениями для Unix. Из тысяч существующих Unix-приложений они взяли 50 самых распространенных и выбрали 1179 функций API в качестве основы нового стандарта, который первоначально был назван SPEC1170. Позднее это название было заменено на «Единая Спецификация UNIX» (Single UNIX Specification), и данный стандарт становится теперь новой промышленной спецификацией Unix. Помимо указанных API в него входит часть интерфейсов POSIX. В состав спецификации продолжают включаться новые API.

Очевидная проблема во всей этой работе по определению API была лаконично сформулирована одним из сотрудников института NIST (National Institute of Standards and Technology Национального института стандартов и технологий США): «Самое милое в стандартах — это большой их выбор». В самом деле, множество противоречащих друг другу и быстро изменяющихся стандартов делает невозможным создание приложения, которое было бы переносимо на все платформы. Далее, в главе 11, мы рассмотрим язык программирования Java и предоставляемые им возможности по созданию переносимых приложений.

Более того, эти стандарты не являются полными, то есть во многих случаях приложениям приходится действовать «в обход» API. В результате приложение становится зависимым от аппаратуры и программного обеспечения нижних уровней: в тот момент, когда приложение обходит API, все проблемы, присущие процессоро-ори-ентированным архитектурам, возникают снова.

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

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

Независимый от технологии машинный интерфейс (Technology-Independent Machine Interface), который часто называют просто MI[ 9 ], представляет собой формальное определение интерфейса для всех приложений и большинства компонентов операционной системы. Аппаратура, а также все программное обеспечение операционной системы, которому должны быть доступны подробности аппаратной реализации, располагаются ниже границы 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 на другой аппаратуре требовался эмулятор.

Отрицательная сторона интеграции — отсутствие гибкости. В интегрированных решениях обычно имеет место подход «все или ничего». Клиент не может выбрать

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

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

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

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