Основы AS/400 - Фрэнк Солтис
Шрифт:
Интервал:
Закладка:
Первый NUI, созданный для IBM Network Station гораздо менее радикален. Он разрабатывался так, чтобы сохранить привычный пользователю внешний вид. С помощью отдельных окон на экране можно запускать терминальную эмуляцию для приложений 5250/3270, приложения Unix motif, браузер и стандартные приложения Windows. Со временем этот интерфейс может быть расширен для поддержки специфических NUI, требующихся пользователям AS/400. Несколько лет уйдет на то, чтобы отобрать все наилучшие для рабочего стола возможности — идеал, которого, вероятно, не достигнет ни один интерфейс.
Будущий рост производительности всех систем позволит применять еще более простые интерфейсы, в том числе воспринимающие голос и рукописный текст. Подобный прогресс значительно увеличит число пользователей компьютеров за счет тех людей, на чьем видеомагнитофоне со дня покупки так и мигает «00:00».
Хотя распространение новых интерфейсов будет зависеть от культурных и географических факторов, к 2001 году мы станем свидетелями размывания границ между традиционными видами человеческой деятельности: работой в офисе, дома, или в дороге, ведением личных дел, обучением и отдыхом. Происходит быстрое слияние рынков компьютеров: развлечений, коммуникаций, и потребительского (возможно, дойдет даже до того, что Doom[ 89 ] будет работать «вживую» на AS/400).
Технологии приложений
В главе 11 я потратил много места на обсуждение трех моделей приложений, на развитие которых направлены основные инвестиции в версию 4 (сетевые, совместные и клиент-серверные вычисления). Ожидается, что эти направления сохранятся и в дальнейшем. Пока не похоже, что в ближайшем будущем их заменят какие-либо другие, но в то же время, мало кто мог еще несколько лет назад предсказать быстрое распространение, например, сетевых вычислений. Возможно, в ближайшие 5-10 лет появится новая модель приложений, но какой она будет? В любом случае, я не сомневаюсь, что способность AS/400 осваивать новые модели не подведет.
Было бы замечательно, если бы любое приложение отлично работало на любой системе, но увы... Многие заказчики AS/400 хотят работать с приложениями, написанным для другой системы, или точнее для другой операционной системы. Интегрированные серверы приложений, описанные в главе 11, почти всегда позволяют им это. Конкретно, на этих серверах могут исполняться приложения, написанные для OS/2, AIX и Windows NT. Если наших заказчиков увлечет какая-либо другая ОС, IBM легко добавит ее поддержку в новые интегрированные серверы.
Основой разработки новых приложений станет объектно-ориентированная технология. Уже доказано, что она может значительно поднять продуктивность и самой разработки, и полученных в результате новых приложений. Традиционные процедурные программы будут расширяться до тех пор, пока не окажутся полностью переделанными или замененными. Этот процесс займет многие годы.
Самая большая проблема объектно-ориентированной технологии — требуемый ею уровень подготовки. В результате разработка и настройка будущих приложений будут выполняться на нескольких уровнях с разными требованиями к подготовке программистов. Например, только относительно небольшая группа профессионалов, создающих ОС и средства разработки приложений, будут использовать собственно объектно-ориентированные языки, такие как С++ (часто сравниваемый с обоюдоострой бритвой). Поставщики решений и ISV, вероятно, будут использовать такие языки как Java, а также настраиваемые каркасы и готовые компоненты, например, из проекта San Francisco. Прикладные программисты, по-видимому, предпочтут визуальное соединение компонентов, а пользователи, программирующие от случая к случаю, — дружественные интерфейсы и самообучающиеся средства.
Еще до 2001 года мы узнаем, работает ли подход Java «Пишется однажды — исполняется везде». Учитывая, что виртуальная машина Java реализована для всех основных платформ, вполне возможно создание Java-приложения, работающего на всех платформах. Насколько универсален такой подход — предмет споров. Объектно-ориентированные технологии предоставляют нам принципиально новый способ разработки программ. А как быстро и плодотворно мы сумеем этим воспользоваться — покажет только время. Но общее направление поисков для большинства специалистов очевидно.
Общая производительность системы
В этой и предыдущей главах мы говорили о будущем AS/400, включая планы по значительному повышению производительности системы, удовлетворению потребностей новых приложений. Надеюсь, читателям ясно, что наши намерения создать в будущем новые высокопроизводительные версии системы AS/400, вполне обоснованы. Но что можно сказать о сегодняшнем дне? Как выглядит серия AS/400е на фоне своих конкурентов?
Недавно я просматривал результаты тестов на производительность по нескольким вычислительным системам и размышлял о методиках ее измерения. Как часто, все же, мы предпринимаем смешные попытки свести всю нужную заказчику информацию о данном компьютере к одной цифре!
Чаще всего в роли такого «универсального» показателя выступает тактовая частота процессора в мегагерцах. Как Вы помните, тактовая частота эквивалентна оборотам двигателя автомобиля — она показывает, как быстро «крутится» двигатель, но ничего не говорит об объеме выполняемой работы. Многие современные процессоры «крутятся» очень быстро, но при этом выполняют незначительную работу. Тестовые программы должны давать нам представление о том, какой объем работ выполняется на самом деле.
Программы тестирования производительности
Сегодня существует великое множество разнообразных программ тестирования производительности, так что выбор той, которая больше Вам подходит — дело нелегкое. Среди производителей компьютеров наиболее широко распространены тесты, созданные независимыми разработчиками, — SPEC (Standard Performance Evaluation Corporation) и TPC (Transaction Processing Performance Council).
SPEC образована в 1988 группой фирм — производителей компьютеров для разработки набора тестов для рабочих станций и серверов Unix. Набор тестов SPEC представляет собой группу программ, написанных на С и Fortran. По одним из них, ориентированным на обработку целых чисел, вычисляется показатель SPECint, по другим, ориентированным на операции с плавающей запятой, — показатель SPECfp. Для определения производительности тестовые программы запускают по очереди, замеряя время их выполнения. Итоговым значением считается среднее геометрическое (перемножение n чисел с последующим извлечением корня n-ой степени) промежуточных результатов.
Первым набором тестов этой серии был SPEC89 (89 — год создания) из 10 программ (4 целочисленных и 6 с плавающей запятой). В SPEC92 число программ возросло до 20, а в последнюю версию SPEC95 были добавлены еще несколько дополнительных программ. Сейчас ведется работа над SPEC98.
Так как тестовые программы очень малы и выполняются по одной, то обычно программа целиком умещается во внутреннюю кэш-память процессора. В SPEC95 было добавлено несколько программ большего размера, но и кэши так же растут. В результате, SPEC может измерить «грубую силу» процессора, но не производительность системы в целом, так как эти тесты не охватывают память и подсистему ввода-вывода. В результате, SPEC применяется, в основном, для измерения производительности однопользовательской рабочей станции Unix. И, как можно было предсказать заранее, процессоры с большими значениями МГц, такие как Digital Alpha, показывают на этих тестах очень хорошие результаты.
Тесты ТРС предназначены для измерения общей производительность системы, а не только процессора. В соответствии с программным заявлением, ТРС — это бесприбыльная организация, чья цель — организация тестирования обработки транзакций и баз данных, а также распространение объективных и проверяемых результатов этих тестов. В ТРС сейчас 45 членов, в их числе все основные производители компьютеров.
ТРС определяет свои тесты в терминах деловых транзакций. Например, обычная транзакция ТРС включает обновление базы данных для таких приложений, как управление инвентарным списком (товары), заказом авиабилетов (обслуживание) или банковскими операциями (деньги). На сегодня основные тесты этой группы — ТРС-С и ТРС-D.
ТРС-С представляет собой тест OLTP. В процессе его пять транзакций разного типа и сложности выполняются либо параллельно, либо помещаются в очередь для отложенного исполнения. База данных содержит девять типов записей, которые сильно различаются размерами. ТРС-С измеряется в транзакциях в минуту (tpm).
ТРС-С моделирует реальную вычислительную среду, где группа операторов за терминалами выполняют транзакции с обращением к базе данных. Назначение теста — проверка скорости выполнения единичных операций (транзакций) в системе обработки заказов, например, таких, как прием и доставка заказов, регистрация выплат, проверка состояния заказа и контроль за наличием товаров на складе. Хотя данный тест имитирует работу оптового поставщика, ТРС-С не ограничен каким-либо конкретной отраслью, а представляет любой бизнес по продаже или распространению товаров или услуг.