Основы AS/400

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

«Это там есть; все там есть!», — восклицает телевизионная реклама известного соуса для спагетти. Вместо того, чтобы покупать ингредиенты и делать соус самому — убеждает голос за кадром — лучше просто купить бутылку этого соуса и быть уверенным, что все качественные и свежие составляющие, которые Вы использовали бы, уже там. Гленн Ван Беншотен (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 на другой аппаратуре требовался эмулятор.

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

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

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