Основы AS/400 - Фрэнк Солтис

Более того, эти стандарты не являются полными, то есть во многих случаях приложениям приходится действовать «в обход» 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 на другой аппаратуре требовался эмулятор.

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

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

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

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