• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

Почему я так уверен в будущем AS/400? В этой главе мы рассмотрим ПО и аппаратуру версии 4, и Вы получите представление о ближайших перспективах этой системы. Глава 12 посвящена версиям AS/400, следующим после 4. И пусть пока трудно сказать что-то конкретное, но уже есть достаточно обоснованные предположения относительно новых технологий, которые изменят всю индустрию информатики в следующие 5-10 лет. Я намерен высказать свое мнение о том, как эти технологии повлияют на AS/400.

Конечно, всякие предположения — это лишь предположения. Мы живем в эпоху постоянных перемен, и создаем компьютерные технологии в соответствии с ее требованиями. Предсказывать будущее различных аппаратных и программных технологий легче легкого; тяжело лишь выбрать, какие из них подойдут для решения конкретных проблем. Разумеется, у IBM свои планы на этот счет, но так как они еще не устоялись, а также из соображений защиты интересов корпорации в конкурентной борьбе, я не буду обсуждать эти планы подробно. Но и не постесняюсь сделать определенные прогнозы насчет основных тенденций развития информатики и их влияния на AS/400.

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

Как я уже говорил, версия 3 ознаменовала переход на RISC-процессоры. Отдельные версии OS/400 для CISC- и RISC-систем позволили заказчикам пользоваться старыми и новыми моделями с равной функциональностью. С объявлением в 1997 году версии 4, ситуация изменилась. Новые возможности этой версии будут реализованы только на RISC-моделях. Возможно, некоторых из новых функций будут доступны и на CISC-моделях, но IBM не будет больше эквивалентно поддерживать системы разных архитектур. Но, конечно, приложения, написанные для CISC-модели, в версии 4 работают по-прежнему без изменений, полностью используя возможности RISC-ап-паратуры.

С момента первого появления AS/400 в 1988 году, срок жизни версии OS/400 составлял три года. У каждой версии было разное число выпусков, но эта цифра оставалась неизменной. У меня нет причин сомневаться, то и версию 4 ждет та же судьба. Новые выпуски начались в 1997 году и, наверняка, будут продолжаться до 1999 года. Учитывая быстроту изменений в окружающем нас мире, вероятно, у версии 4 будет еще больше выпусков, чем у предыдущих. И если история повторится, то примерно к 2000 году можно ожидать или новой версии, или совершенно новой системы. В следующей главе я постараюсь спрогнозировать, что будет с AS/400 после 2000 года.

IBM вкладывает большие средства в развитие различных компонентов AS/400. На рисунке 11.1 показаны области связанных с электронным бизнесом капиталовложений в версию 4[ 80 ]. Эти инвестиции отражают предполагаемые направления развития компьютерной индустрии в соответствии с нуждами наших заказчиков в течение нескольких следующих лет. Они также указывают на те расширения, которые Вы можете ожидать в AS/400.

Рисунок 11.1. Поддержка е-бизнеса в AS/400

Итак, поговорим о перспективных направлениях развития AS/400. В этой главе мы рассмотрим:

три модели приложений — сетевые, совместные и клиент-серверные вычисления; два направления развития ПО — поддержку приложений и оптимизацию обработки данных;

две ветви развития аппаратных средств — расширения в старших моделях и улучшение соотношения цена-производительность.

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

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

Революцию, произведенную ПК, можно считать свершившимся фактом. Она коренным образом и повсеместно изменила всю систему бизнеса. А вот в отношении клиент-серверной модели подобная категоричность еще не вполне уместна. Многие фирмы находят ее вполне подходящей для ведения своих дел, но есть и те, кто считает, что дороговизна и сложность клиент-серверных вычислений не перевешивают получаемых от них выгод. В следующем разделе мы посмотрим, как AS/400 упрощает клиент-серверные вычисления, делая их более привлекательными для заказчиков.

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

Сетевые вычисления — одна из таких новейших технологий. Многие (и я в том числе) считают, что эффект от этого следующего поколения клиент-серверных вычислений изменит бизнес больше, чем революция,произведенная ПК. Сетевые технологии уже изменили наш образ жизни и работы. Интернет, и особенно появление в 1993 году WWW (Word Wide Web), сделали то же, что в свое время электричество или телефон. По мере расширения доступа к всемирной сети компьютеров географические границы исчезают. В киберпространстве уже появились свои сообщества, в которых люди сходных интересов могут объединяться для обмена информацией и общения с помощью комнат переговоров (chat room) и дискуссионных форумов. Колонизация киберпространства предоставляет бизнесу новые, ранее недостижимые, возможности целенаправленной работы с определенными группами потенциальных клиентов.

Очевидно, что движущая сила перехода к сетевым вычислениям — потребности рынка. Благодаря сетевым вычислениям, предприятия могут резко увеличить свою конкурентоспособность: Интернет позволяет поддерживать с клиентами и смежниками самый тесный и постоянный контакт. Кроме того, постепенно распространяется понимание преимуществ использования Интернета внутри организации. Многие фирмы сейчас реализуют интранеты. Интранет использует технологии Интернета на внутренней закрытой сети, которая может быть локальной или охватывать все предприятие.

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

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

Различные предлагаемые AS/400 сетевые возможности, а также используемые для их поддержки стандарты Вы можете видеть на рисунке 11.2. Впервые IBM представила Internet Connection в 1996 году как часть TCP/IP Connectivity Utilities в OS/400 и продолжает совершенствовать это ПО в каждом выпуске версии 4.

Рисунок 11.2. Поддержка Интернета в AS/400

Многие сокращения, использованные на рисунке 11.2, расшифровывались и пояснялись в главе 7 при обсуждении защищенного сервера WWW. Некоторые из этих пояснений я повторю. Мы не будем подробно рассматривать каждый компонент, а лишь постараемся оценить широту диапазона функций AS/400 для обслуживания Интернета и интранетов. Важно отметить, что и новые, и существующие приложения поддерживают выход в сетевой мир. Итак:

Any Mail — позволяет использовать AS/400 в качестве сервера электронной почты, поддерживая соответствующие стандарты;

SMTP (Simple Mail Transfer Protocol) обеспечивает посылку и прием электронной почты;

сервер POP (Post Office Protocol) — почтовый ящик, в котором почта хранится до тех пор, пока ее не заберет реципиент (последняя версия данного стандарта — РОР3);

IMAP (Internet Message Access Protocol) поддерживает синхронизацию локальных данных на множественных узлах Интернета (например, компьютер дома и компьютер на работе), что позволяет большим массивам электронной почты «перетекать» с компьютера на компьютер;

MIME (Multipurpose Internet Messaging Extensions) — это стандарт Интернет для посылки почты с заголовками, описывающими содержимое почтового сообщения; при этом сообщения могут содержать файлы, видео, картинки, звук, текст или двоичные данные;

SMIME (Secure Multipurpose Internet Messaging Extensions) — вариант MIME с обеспечением секретности.

Клиенты WWW могут работать с существующими приложениями 5250 с помощью Telnet, который обеспечивает терминальную эмуляцию 3270, 5250 и VT100 по сети или с помощью HTML Gateway. HTML (Hypertext Markup Language) — это формат потока данных между сервером WWW и браузером на пользовательской машине. HTML Gateway позволяет графически отображать приложения 5250 с помощью браузера.

Стандартный транспортный протокол Интернета, известный как HTTP (Hypertext Transport Protocol), используется Internet Connection Secure Server и Internet Connection Server для обмена информацией с клиентами WWW. Отличие между этими двумя серверами в том, что один защищен, а другой нет. Выбор того или другого зависит от конкретных обстоятельств, о которых мы еще поговорим.

Вы можете использовать несколько протоколов для доступа к IFS (Integrated File System), которая поддерживает файлы HTML и Java. На рисунке 11.2 показаны серверы для двух таких протоколов. Есть также серверы и для других протоколов: это сервер BootP (BootStrap Protocol), сервер TFTP (Trivial FTP), сервер Telnet и сервер RIP (Routing Information Protocol).

CGI (Common Gateway Interface) — это стандартный протокол сервера WWW, позволяющий программам, расположенным на сервере, напрямую взаимодействовать с браузером на пользовательском компьютере. Приложения CGI — стандарт для сетевых приложений на всех остальных серверах, они также поддерживаются и AS/ 400. Альтернатива программам CGI — макропроцессор Net.Data, упрощающий доступ к DB2/400 из WWW.

TCP/IP (Transmission Control Protocol/Internet Protocol) — это промышленный стандарт передачи данных по Интернету. Физические подключения могут осуществляться по выделенным линиям, асинхронным телефонным линиям и ЛВС. В случае подключения к Интернету по телефону можно использовать любой из двух протоколов: SLIP (Serial Link Internet Protocol) или PPP (point-to-point protocol). В качестве ЛВС могут использоваться Token-Ring, Ethernet со скоростью до 100 Мбит в секунду, беспроводные сети или новые сети ATM (Asynchronous Transfer Mode) со скоростью до 155 Мбит в секунду.

Защита на Интернете крайне важна, особенно при коммерческих операциях. Расширения сетевой защиты продолжают добавляться к AS/400 либо как часть базовой поддержки в составе OS/400, либо как отдельные продукты. Например, базисная аутентификация HTTP — часть базовой поддержки. Она запрашивает у пользователя идентификатор и пароль при попытке обратиться к странице WWW с ограниченным доступом. Таким образом, профили пользователей AS/400 или отдельный список пользователей сервера могут применяться для разграничения доступа пользователей к страницам WWW.

Internet Connection Secure Server для AS/400 — отдельный продукт, обеспечивающий секретность коммуникаций в WWW. Он позволяет браузерам и серверам WWW выполнять взаимную аутентификацию, обеспечивает владельцев узлов WWW возможностью управлять доступом к серверу и позволяет передавать между браузером и сервером закрытую информацию так, чтобы она была недоступна третьим лицам. В своей работе Internet Connection Secure Server использует SSL (Secure Sockets Layer) фирмы Netscape. SSL предоставляет закрытый канал между пользователем и сервером, гарантируя защиту данных, аутентификацию участников сессии и целостность сообщений. Обратите внимание, что на SSL на рисунке 11.2, используется именно Internet Connection Secure Server, а не Internet Connection Server.

Защиту при обслуживании WWW обеспечивают такие продукты AS/400, как аппаратное шифрование данных и брандмауэры. Мы обсудили их в главе 7.

Еще более надежную защиту дает прокси-сервер, выступающий посредником между пользователем и сервером WWW. Запрос пользователя направляется на прокси-сервер, который выполняет запрос к серверу WWW, а затем возвращает клиенту результаты.

Новый продукт IBM для AS/400 под названием Net.Commerce (на рисунке 11.2 не показан) позволяет разрабатывать собственные торговые системы для Интернета. Он предоставляет средства для создания и управления интерактивным сетевым магазином. С помощью функции построения каталога Вы можете определить категории или отделы, переходя по которым покупатели добираются до продаваемых продуктов. Net.Commerce применяет как DB2/400, в которой размещается как вся информация каталога, так и Internet Connection Secure Server. Для обеспечения защиты платежей по Интернету Net.Commerce использует протокол SET (Secure Electronics Transaction), описанный в главе 7.

Первые залпы этой битвы прогремели 4 сентября 1995 года. Место сражения — форум в Париже, где всеобщее внимание привлекла речь Ларри Эллисона (Larry Ellison), главы фирмы Oracle. Он сказал: «По нашему мнению, в мире происходит переход от ориентации на рабочие места к ориентации на сети. Вы можете поставить терминал всего за 400-500 долларов США. При этом такое дорогое и сложное устройство, как ПК, становится нелепым анахронизмом. Гораздо проще воткнуть вилку в розетку и таким образом получить нужные данные». Так Эллисон заявил концепцию сетевого компьютера (СК). Битва началась.

В парижском форуме участвовал и Билл Гейтс (Bill Gates), глава Microsoft — компании-лидера на рынке «нелепых анахронизмов» ПК. Речь Ларри Эллисона явно задела его самолюбие и Гейтс нанес ответный удар, сказав, что «тупой терминал» Эл-лисона никогда не будет доминировать среди настольных устройств. Комментируя утверждение Эллисона, что будущее настольное устройство будет удешевлено за счет отсутствия дисковой памяти, Гейтс сказал: «Вам по-прежнему потребуется способ хранения информации, полученной из сети, а также своих личных данных».

С этого момента компьютерщики всего мира встали по ту или иную сторону баррикад. С одной стороны бой вели Oracle, Sun Microsystems, Netscape, Apple и IBM, с другой — Microsoft, Intel и другие производители ПК, которые потерпели бы наибольшие убытки в случае распространения СК.

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

Цифры, представленные в 1996 году Gartner Group, Inc. из Стамфорда (Stamford), штат Коннектикут, показали, что ОСВ ПК за типичный амортизационный период в три-пять лет составляет более 40 000 долларов или 8 000—13 000 долларов в год. Gartner Group также подсчитала, что эквивалентная стоимость ПК в 1987 году была менее 20 000 долларов, то есть за последние 10 лет ОСВ удвоилась.

Gartner Group строила свои расчеты исходя из методики четырех основных составляющих ОСВ ПК. Цена самого ПК — около 21 процента, затраты на администрирование —еще около 9 процентов, на техническую поддержку — 27 процентов. Огромные 43 процента стоимости падают на «операции конечного пользователя», то есть пользователь плохо использует ПК, теряя время на установку специального ПО или аппаратуры, или тратит ресурсы машины на задачи, не связанных с основной работой. Глава Sun Скотт Мак Нили (Scott McNealy) утверждает: «Фактором, предрешающим победу СК, будет ОСВ... Мы собираемся снизить ее до 2 500 долларов в год».

20 мая 1996 года Oracle, Apple, Netscape, Sun и IBM выпустили первое руководство по СК под названием Network Computer Reference Profile. Этот документ должен был «обеспечить общий подход к созданию популярных и широко распространенных вычислительных технологий на всем диапазоне масштабируемых сетевых вычислительных устройств, включая персональные компьютеры». Подразумевалось, что создатели ПК могут присоединиться к этой программе, оснастив свою продукцию всеми атрибутами СК. При этом вопрос, сможет ли ПК с его большим жестким диском и памятью конкурировать с «облегченными», построенными в соответствие с новым общим подходом, устройствами, оставался открытым.

Network Computer Reference Profile определил ресурсы пользовательского интерфейса, такие как терминал VGA, указательное устройство и возможность ввода текста. Были также заданы коммуникационные протоколы, которых должны поддерживаться, чтобы обеспечить ориентацию СК на работу с сети. Таковыми объявлялись, в частности TCP/IP, Telnet с поддержкой терминалов 3270 и 5250 и SNMP (simple network management protocol). Кроме того, перед СК ставилась задача: поддерживать основные стандарты WWW, такие как HTTP, HTML и виртуальная машина Java (описана в следующем разделе).

Работа над спецификацией СК началась в IBM задолго до того, как Ларри Эллисон в Париже «сделал первый выстрел». Но небольшая группа инженеров в Рочестере была обеспокоена тем, что дело продвигается медленно, и решила создать свой собственный СК. В конце концов, говорили они, AS/400 — идеальный сервер для такого устройства, особенно если его оснастить шлюзом HTML (это планировалось на 1996 год). Под руководством инженеров Гленна Баталдена (Glenn Batalden) и Лу Беренса (Lou Behrens) эта небольшая группа быстро разработала свой СК на PowerPC. Они решили поместить свое творение в маленькую темную башенку размером примерно со среднего размера книгу, и даже скруглили заднюю часть корпуса, что оно больше походило на крошечную AS/400. В апреле 1996 года разработчики продемонстрировали прототип нового СК на конференции группы пользователей COMMON в Сан-Франциско, вызвав восторженные отклики заказчиков. После этого соответствующие службы немедленно занялись планами поставок нового СК на рынок.

5 сентября 1996 года инженеры Рочестера с гордостью представили миру свое детище, получившее имя IBM Network Station. Новый компьютер был первым СК, разработанным в соответствии с документом Network Computer Reference Profile. Новый СК подключается к серверам IBM и других фирм, но черный цвет и скругленная задняя часть ясно выдают его происхождение от AS/400. 29 октября 1996 года Sun представила свою версию СК — JavaStation. Затем появились и СК других производителей, также созданные в соответствии с общей спецификацией. Эти СК построены на RISC-процессорах различных фирм и используют собственные ОС, обычно на основе Unix.

Чтобы противостоять такому напору СК, за день до презентации Sun JavaStation, Microsoft и Intel объявили о своей разработке руководящей спецификации настольного компьютера нового типа, который они назвали NetPC. Подобно СК, NetPC проще обычного ПК, и кроме того, менее гибок и менее расположен к модернизациям. В отличие от СК, NetPC построен на процессоре Intel Pentium и работает только с Windows. В NetPC встроен жесткий диск.

Спецификация NetPC не планирует покупную стоимость системы ниже 500 долларов. Ее назначение — лишь сократить стоимость владения ПК, а также создать систему, которой легче управлять в корпоративной среде. Для этого в NetPC используются две новые концепции: одна от Intel под названием Wired for Management, а другая от Microsoft под названием Zero Administration for Windows. Wired for Management разработана Desktop Management Task Force, учрежденной несколькими компаниями в 1992 году. Она предоставляет собой продукт, который подразделения техобслуживания ПК могут использовать для упрощения управления ПК, подключенных к ЛВС. Концепция Zero Administration фирмы Microsoft включена в ОС Windows для автоматического обновления ОС NetPC с сервера при загрузке NetPC, а также для автоматической установки приложений при вызове их пользователем. Кроме того, все созданные или введенные пользователем данные могут автоматически копироваться на сервер, благодаря чему у пользователя всегда будет доступ к ним, независимо от того на каком NetPC в сети он работает. Центральный администратор также может управлять всеми аспектами конфигурации NetPC по сети.

Кто же победит в битве за рабочий стол? Скорее всего, фирмы-заказчики. Как СК, так и NetPC обладают возможностями снижения ОСВ. Конкретный тип рабочего места будет зависеть, в конечном счете, от используемых организацией приложений и серверов. Традиционным клиент-серверным приложениям, вероятно, по-прежнему лучше подойдут полноценные ПК. Если же, как утверждают сторонники СК, будущие клиент-серверные приложения будут писаться на Java, то победят приверженцы СК. NetPC также не останется без дела, но полностью его преимущества раскрываются только тогда, когда и сервер, и все пользователи работают исключительно под Windows. В этом отношении СК, который может работать с любым сервером, гораздо более гибок. И не забывайте о тысячах и тысячах приложений, написанных для терминалов 3270 и 5250. Здесь годятся и СК, и ПК. AS/400 поддерживает всех пользователей, начиная от 5250 и заканчивая СК и ПК. Более того, в сети возможны любые сочетания таких пользователей, что позволяет каждому из них оборудовать свое рабочее место так, как ему нравится.

Рабочим группам, состоящим из сотрудников одной или нескольких организаций, необходимо взаимодействие и разделение информации. В этой связи многих привлекает клиент-серверное ПО для рабочих групп, обычно называемое групповым ПО (groupware). В основе группового ПО лежит модель совместных действий нескольких пользователей, работающих в группе над общими задачами. Поэтому второе название такой модели — модель совместных вычислений (collaborative computing). Типичные примеры совместных вычислений — создание документа аналитической группой, проведение конференций, участники которых географически удалены друг от друга, или просто обмен электронной почтой.

Общий объем применения группового ПО быстро растет. IBM полагает, что 1999 во всем мире у него будет более 250 миллионов пользователей. Мы прилагаем значительные усилия для того, чтобы AS/400 стал для этих пользователей наилучшим сервером.

Сервер группового ПО поддерживает пять основных видов деятельности.

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

Электронная почта. Этот простой и удобный способ связи очень быстро распространился по всему миру и используется как внутри оргструктур, так и для внешних контактов между ними. Сервер группового ПО в качестве сервера электронной почты должен поддерживать различные системы электронной почты ПК (например, Lotus cc:Mail, Microsoft Mail или Internet Mail). Обычно для этой цели серверу служат стандартные почтовые API. Серверы электронной почты также должны предоставлять шлюзы в различные системы электронной почты, доступ к которым требуется обслуживаемым организациям.

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

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

Автоматизация деловых процедур (АДП). Технология, известная как АДП (workflow), — средство сократить время, затрачиваемое на различные этапы производственной деятельности: например, на получение и выполнение заказов клиентов или управление техобслуживанием компьютеров. Идеи АДП лежат в основе организационной перестройки многих фирм. В рамках этой технологии работа автоматически передается от одной программы к другой. АДП определяет операции, которые должны выполняться на каждом шаге, и действия, которые нужно предпринять при возникновении исключительных ситуаций. АДП произошла от АСУП (автоматизированная система управления производством) — средства оптимизации и автоматизации последовательности производственных операций. Теперь АДП применяется и во многих других областях, например, в конторской работе с большим документооборотом. Представим себе страховую компанию, где занимаются обработкой страховых претензий клиентов. Подобно производственному конвейеру, обработка претензий включает множество операций с участием большого числа людей; отличие состоит в том, том обработка претензии выполняется на бумаге и не связана с физическим перемещением изделия. Если бумага становится электронным документом, то компьютер может обрабатывать передачу документа с одного этапа процесса на другой автоматически. В такой системе сервер получает запросы и уведомления о событиях и интерпретирует их в соответствии правилами, определенными пользователем. Затем сервер направляет работу соответствующему сотруднику. Сервер также отслеживает прохождение работ, гарантируя, что они выполняются в срок и теми, кто обязан это делать.

Сервер группового ПО объединяет пять компонентов, соответствующих этим видам деятельности в интегрированную среду. Например, когда компонент АДП определяет, что в некий процесс должен быть вовлечен дополнительный сотрудник, сервер может для уведомления сотрудника воспользоваться компонентом электронной почты. Добавьте к этому поддержку WWW, обеспечивающую доступ к серверу с любого терминала из любой точки мира, и Вы получите современный продукт группового ПО, такой как Lotus Notes, Netscape SuiteSpot или Microsoft Exchange.

Вероятно, лучший продукт группового ПО на сегодняшний день — Lotus Notes. Его серверная часть, известная как Domino, доступна на AS/400. Domino полностью интегрирован с другими компонентами AS/400, включая DB2/400 и почту AS/400. Он отлично поддерживает WWW, что обеспечивает доступ к нему с помощью любого браузера, не требуя наличия ПК с клиентской частью Notes. Domino может действовать на интегрированном ПК-сервере — Integrated PC Server (IPCS) на всех моделях AS/ 400. На IPCS работают и другие продукты группового ПО и АДП. Мы подробно рассмотрим это в следующем разделе.

Встроенная поддержка, известная как Domino for AS/400, имеется только на RISC-моделях в составе версии 4. В прежних версиях AS/400 можно установить до 16 плат IPCS, каждая из которых выполняет Domino и поддерживает около 150 пользователей Notes. Но все же встроенная поддержка обладает большей производительностью и поддерживает тысячи пользователей Notes, а также обеспечивает более тесную интеграцию с данными. Например, встроенный драйвер Domino устраняет надобность в ODBC или каком-либо другом пакетном интерфейсе для доступа к данным AS/ 400. Встроенный Domino также использует многие средства AS/400, включая защиту и управление разделяемыми каталогами. Короче говоря, все те средства, благодаря которым AS/400 получила всеобщее признание, теперь доступны Domino.

Хотя мы уже говорили о клиент-серверных вычислениях, я, по сути, так и не определил термин клиент-сервер. Часто даже организации, использующие клиент-серверные вычисления (когда приложение разбивается между серверами и ПК), не имеют ясного представления, что это такое. Поэтому мы кратко рассмотрим модель клиент-сервер, а затем обсудим, чем увенчались усилия IBM по ее упрощению в версии 4.

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

Как бы мы не определяли понятие клиент-сервер, вот его основные характеристики:

в клиент-серверных вычислениях интеллект распределен по сети, а не находятся в каком-то одном месте;

ресурсы сервера, как аппаратура, так и ПО, совместно используются многими клиентами;

местонахождение разделяемых ресурсов прозрачно для пользователя, независимо от того, располагаются эти ресурсы на той же системе, что и клиент, или в любом другом месте сети;

взаимодействие всегда инициируется клиентами, запрашивающими обслуживание, а сервер ожидает от них запросов;

клиент и сервер обмениваются информацией посредством сообщений; соединение между ними может быть либо локальным, либо сетью удаленных коммуникаций;

система рассматривается с точки зрения пользователя.

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

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

По этим и другим причинам многие организации просто не рискуют затевать переход на клиент-серверную модель. Исследование Standish Group показало, что лишь один из шести клиент-серверных проектов (16 процентов) заканчивается успехом, в то время как 31 процент — преждевременно прекращается, а остальные просто терпят неудачу. Эти цифры не слишком воодушевляют начинающих, но, в конце концов, кто сказал, что все должно быть легко?

Так как модель клиент-сервер сложна и ее внедрение дорого, многие пользователи AS/400 по-прежнему работают только с централизованными приложениями, используя в качестве терминалов 5250 или ПК. Но, хотя они часто заявляют о намерении перейти в будущем к клиент-серверным вычислениям, все же подход «поживем — увидим» будет доминировать в их сознании до тех пор, пока преимущества новой модели не станут очевидными.

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

О Client Access кратко упоминалось в главе 5. Эти продукты появились в 1994 году на замену PC Support/400. Хотя последний успешно работал примерно на 80 процентах всех AS/400, через 11 лет потребовалась что-то новое. Нашим ответом на вопрос, заданный временем, стал Client Access.

Продукты семейства Client Access поддерживают различные ОС, включая Windows 3.1/95/NT, OS/2, Unix и Macintosh. Client Access представляет собой единый интегрированный пакет, куда входят средства поддержки:

соединений с обеспечением независимости от протокола;

графического интерфейса пользователя;

эмуляции дисплея 5250;

сервисов печати;

почтовых и офисных сервисов;

мультимедийных функций;

защиты;

управления системой;

доступа к базе данных;

пересылки файлов;

приложений и API.

Новые расширения семейства Client Access будут сопровождать каждый выпуск версии 4. Сейчас я хочу лишь познакомить Вас с некоторыми предоставляемыми им возможностями упрощения клиент-серверных вычислений, не рассматривая все средства Client Access подробно. Однако два новейших расширения требуют большего внимания, так как они сильно влияют на управление системой клиент-сервер и создание соответствующих приложений.

Добавление нового графического интерфейса администрирования системы в Client Access для пользователей Windows 95/NT сделало удобнее работу с AS/400 для тех, кто предпочитает ПК. Новый интерфейс, названный Operations Navigator, упростил выполнение многих пользовательских задач через панель Windows. Например, при регистрации нового пользователя в системе сразу же автоматически создается профиль пользователя, данные о нем добавляются в системный справочник, и он регистрируется как пользователь Notes или NetWare. Графический интерфейс Windows позволяет осуществлять и многие другие административные действия для AS/400, такие как администрирование базы данных, поддержка резервного копирования, политика защиты и аудита, поддержка принтеров и заданий. Operations Navigator обеспечивает единый интерфейс к ресурсам как ПК, так и AS/400, что значительно упрощает администрирование клиент-серверных конфигураций с участием пользователей Windows. Тем, в конечном счете, нужно освоить только один дополнительный интерфейс.

Еще одно расширение, на котором мы задержим свое внимание, имеет кодовое название Project Lightning. Этот продукт обеспечивает эффективный и легкий доступ к базе данных AS/400 для 32-разрядных Windows-приложений. Он предназначен для работы в среде Windows, что достигается соответствием стандартам СОМ/OLE (будут обсуждаться далее в этой главе) и ActiveX. Встроенные модули Visual Basic обеспечивают программистам легкий доступ к хранимым процедурам, базам данным, программам, очередям данных и командам. По командам меню Windows на экран выводятся мастера, которые направляют программиста в процессе подключения к различным функциям AS/400. Фактически, мастера генерируют код, необходимый для обращения к каждой функции AS/400. Затем программисты могут модифицировать код вручную или продолжать генерировать его с помощью мастеров.

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

Следующие разделы посвящены четырем другим основным направлениям модификации AS/400 в версии 4 — двум программным и двум аппаратным. Это также не единственные, но самые заметные расширения.

Мы уже обсуждали новые продукты поддержки приложений и в этой, и в предшествующих главах. Вероятно, наиболее значительна в AS/400 поддержка Java. Java быстро становится универсальным языком разработки приложений. По некоторым оценкам уже сейчас его предпочитают более 500 000 разработчиков. Если это так, что вскоре Java будет доминировать среди языков программирования, доступных всем вычислительным системам. В Java мы, кажется, нашли Святой Грааль — открытый язык разработки приложений.

Язык Java был разработан фирмой Sun Microsystems, Inc. Первоначально он предназначался для прикладного ПО бытовых электронных приборов, но скоро стал использоваться для приложений, выполнявшихся браузерами. В конце 1995 года Sun сделала Java доступной, разрешив загружать со своего сервера WWW компании Java Development Kit (JDK). Лицензии на спецификации языка стали выдавать всем желающим. В компьютерной индустрии этот язык был принят на «ура» и практически единогласно.

Java — объектно-ориентированный язык, похожий на С и С++. Как уже говорилось, он разрабатывался для работы программ на маломощных процессорах, во множестве применяемых в бытовой электронике. Я люблю называть Java упрощенной (de-geeked) версией С++, так как в нем присутствуют многие преимущества последнего, но он не такой сложный. Для обеспечения модульности и быстрой загрузки программ по сети, в модели Java используются небольшие программы, называемые апплетами.

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

Java больше чем просто язык; это целая программная платформа, так как включает виртуальную машину (ВМ), программно моделирующую компьютер. ВМ Java может быть встроена в любую ОС или браузер. Существует и аппаратура, предназначенная специально для Java. Для этих компьютеров Sun создала семейство Java-спе-цифичных микросхем процессора.

Среда для программы Java включает в себя ВМ Java, библиотеки классов Java, загрузчик классов, верификатор байт-кода и интерпретатор байт-кода. Байт-код — это внутреннее представление программы на Java. Он генерируется компилятором Java и не зависит от какой-либо аппаратной платформы. Проще всего описать байт-код как промежуточное представление, аналогичное используемому в AS/400 для других языков. Именно этот байт-код пересылается по сети. Так как Java — интерпретируемый язык, обычно, в состав среды времени выполнения входит интерпретатор байт-кода. Для некоторых приложений скорости интерпретации недостаточно, так что в состав среды времени выполнения может быть включен мгновенный компилятор JIT (just-in-time compiler). JIT-компилятор повышает производительность, преобразуя байт-код Java в машинный код процессора, что устраняет необходимость интерпретации.

Обратите внимание, что байт-код Java может быть сгенерирован при компиляции программы с любого языка, например с недавно разработанного Netscape JavaScript. Компиляторы других языков и генераторы программ различных фирм также могут генерировать байт-код Java.

В настоящее время легко доступны готовые программные (любые: от анимации до элементов деловой логики) компоненты Java Beans[ 81 ], изготавливаемые Sun и другими фирмами. Их применение облегчает написание приложений Java: собрав вместе несколько Beans, можно создать простенький апплет Java без какого-либо программирования. Вы также можете включить Beans как часть в сложное приложение. Далее в этой главе мы рассмотрим среды приложений, сходные с Java Beans.

Главное достоинство Java в том, что он принят всеми основными производителями аппаратных и программных средств[ 82 ]. Программирование на этом языке часто характеризуют так: «Пишется однажды — исполняется всегда». Разработчики, создавая программу на одной машине Java, уверены в том, что она будет работать и на любой другой Java-машине.

У Java по-прежнему есть конкуренты, наиболее значительный из них — набор протоколов OLE (Object Linking and Embedding) фирмы Microsoft с объектами ActiveX. Объекты ActiveX служат в OLE так же, как Beans в Java. В основе OLE — объектная модель Microsoft, известная под названием СОМ (Component Object Model) OLE и COM привязаны к Windows и нескольким другим ОС. Java существует только в ПО, и поэтому мирно сосуществует с любой ОС на любой аппаратной платформе. Благодаря своей универсальности Java, скорее всего, будет лидировать при разработке будущих клиент-серверных приложений.

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

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

Ответ на него очевиден, особенно тем, кто в описании Java как полностью программной платформы, моделирующей компьютер в ПО, уловил что-то знакомое. Аналогичными характеристиками обладает машинный интерфейс (MI) AS/400. Возьмем, например, Advanced 36. Для каждой RISC-модели AS/400 в MI встроена полная «виртуальная машина» System/36, которая может выполнять ОС SSP и все приложения System/36. Более того, набор команд System/36 эмулируется MI, то есть эти команды интерпретируются. Та же концепция лежит в основе байт-кода Java.

Отсюда вытекает, что логичный путь реализации байт-кода Java на AS/400 — расширение MI. Этот подход также схож с тем, что использовался для поддержки программной модели ILE: там мы реализовали W-код (генерируемое компиляторами ILE промежуточное представление) непосредственно в MI. Следующий шаг — реализация ВМ Java (точнее, интерпретатора байт-кода, необходимого для исполнения программ Java) в SLIC, так же как был реализован код System/36.

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

Ключ для повышения производительности Java на AS/400 — встроенные потоки, о которых уже говорилось в главе 9. Хотя традиционные приложения AS/400 не написаны для модели потоков, приложения для других систем обычно создаются именно так. Модель потоков поддерживают и Unix, и NT, так что следует ожидать, что приложения Java, предназначенные для выполнения на нескольких платформах, последуют этому примеру. Поддержание хорошей производительности потоков — крайне важно для AS/400.

На рисунке 9.7 (глава 9) показана взаимосвязь различных средств поддержки приложений (application enablers) — библиотек времени выполнения — для С, С+ + и Java, IFS и библиотек классов для объектов с реализацией встроенных потоков. Очевидно, что реализация встроенных потоков выгодна не только приложениям Java, но также и всем перенесенным приложениям, которые первоначально были написаны для ОС Unix или NT. Например, Domino для AS/400 представляет собой перенос Domino для AIX. Таким образом, Domino для AS/400 также зависит от хорошей работы потоков.

Хотя язык и модель объектов Java — самая большая наша надежда при разработке приложений для разных платформ, AS/400 продолжает поддерживать модель IBM SOM (System Object Model). В отличие от объектной модели Java, SOM не зависит от языка. Объекты SOM описываются на языке IDL (Interface Definition Language) и могут использоваться как объектно-ориентированными, так и языками других типов. SOM основывается на стандарте CORBA (Common Object Request Broker Architecture), разработанном Object Management Group (OMG). Основная цель его создания — сделать открытую, не зависящую от платформы объектную модель, которая будет использоваться разными языками и ОС. Последняя версия стандарта — CORBA-2 — позволяет старым приложениям, написанным на С++ и Smalltalk, взаимодействовать с Java, а также облегчает их перенос на Java.

В соревновании производителей за объектную модель, которая станет стандартом для всей индустрии, лидируют Java и Microsoft СОМ, тогда как OMG CORBA-2 — на третьем месте, то есть отстает. Будущее стандарта OMG CORBA неопределенно. Хотя мы сосредоточили значительную часть усилий по развитию AS/400 на Java, при этом удалось применить многое из предыдущих работ над SOM.

В V3R6 для RISC-моделей появился компонент SOMobjects, обеспечивающий поддержку времени исполнения для SOM на AS/400. SOMobjects поддерживает переносимость классов между разными системами, на которых работает SOM. В состав SOMobjects также включено множество каркасов (framework). Каркас — это набор объектов, применяемый для общего решения некоторой проблемы. Этим он отличается от библиотеки классов, которая имеет более общее назначение, и не обязательно разработана в связи с какой-либо проблемой. С помощью библиотек классов объекты также можно использовать повторно (мы говорили об этом в главе 3 при разборе объектно-ориентированных концепций).

Очень важная часть SOMobjects — каркас DSOM (Distributed System Object Model), который можно использовать для написания приложений на основе распределенных объектов. Каркас DSOM позволяет программе на одном компьютере вызывать метод объекта на другом компьютере. При создании программой экземпляра объекта он может размещаться на удаленной системе. Каркас DSOM определяет, что объект удаленный, и устанавливает связь с каркасом DSOM на удаленной машине. Каркас на удаленной машине создает фактический экземпляр объекта, тогда как локальный каркас

DSOM — тень объекта, называемую заместителем (proxy). Программа взаимодействует с заместителем, а локальный каркас DSOM перенаправляет запросы к реальному объекту на удаленной машине. Данный процесс прозрачен для пользователей.

SOM на AS/400 на шаг опережает его реализации на других системах. На такое утверждение нам дает право поддержка понятия постоянства объекта. Мы обсуждали постоянство в главе 8 при рассмотрении одноуровневой памяти. На других системах время жизни объекта соответствует времени исполнения создавшего его задания. Это ограничение мешает, если Вам нужно использовать объект в нескольких заданиях. В других системах применяются различные варианты решения данной проблемы; например в OS/2 и AIX — каркас Persistence. Эти решения требуют от программиста явно управлять постоянством объекта, обеспечивая периодическое сохранение его содержимого на диске, что может требовать значительных усилий.

AS/400 не использует каркас Persistence, вместо него постоянные SOM-объекты в AS/400 поддерживает одноуровневая память, что не требует усилий программиста. При создании экземпляра SOM-объекта задается, будет ли он защищенным (то есть постоянным в терминах AS/400). Защищенные объекты инкапсулируются и существуют параллельно с уже рассмотренными нами объектами OS/400. Созданный же постоянный объект помещается в каталог IFS, аналогично созданию объекта OS/400 в библиотеке AS/400. Защищенные объекты имеют имена и могут разделяться, сохраняться или восстанавливаться, как и любые объекты OS/400 с помощью соответствующих команд. В MI эти объекты реализованы в виде байтовых пространств. Таким образом, защита постоянных объектов обеспечивается с помощью системных указателей и компонентов контроля доступа SLIC. По соображениям совместимости SOMobjects также поддерживают незащищенные объекты SOM.

С началом внедрения в AS/400 языка и объектов Java, мы смогли использовать поддержку одноуровневой памятью постоянных объектов так же, как поддержку SOM-объектов. Преимущество модели постоянных объектов AS/400 — в меньших накладных расходах системы при работе с объектами. Другим системам для поддержания постоянства объектов и обеспечения их совместного использования несколькими программами приходится выполнять дополнительные команды; постоянно обновлять объекты на диске. Постоянная одноуровневая память не требует подобного обновления, поэтому при работе с объектами AS/400 выполняет меньше команд и обращений к диску, чем другие системы. Как уже говорилось в главе 8, одноуровневой памяти AS/400 не приходится заниматься «сборкой мусора» для разделяемых объектов. Все это означает, что AS/400 имеет явное преимущество в масштабируемости сервера Java, его способности поддерживать приложения Java и пользователей перед другими аналогичными системами.

Лаборатория IBM в Торонто разрабатывает инструментальные средства типа VisualAge for Java, помогающие пользователям совмещать приложения Java на разных платформах. VisualAge for Java обеспечивает интегрированную среду разработки таких приложений. Бизнес-партнеры AS/400 также предоставляют разнообразные средства разработки для Java. Пользователи, желающие использовать Java прямо сейчас, могут сделать это с помощью VisualAge for Java. Полная среда Java на AS/400, выпущенная в начале 1998 года, включает встроенные потоки, значительно повышающие общую производительность системы.

В 1994 году группа разработчиков приложений AS/400 предложила лаборатории в Рочестере подумать о разработке новой базы приложений на основе объектных технологий. Общая прикладная база давала возможность избежать больших расходов и

риска в ходе объектно-ориентированного программного проекта, получившего название San-Francisco.

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

Основой San-Francisco были избраны С+ + и SOM. Но в начале 1996 года мы попробовали обучать бизнес-партнеров созданию SOM-объектов с помощью этих языков и пришли к выводу, что они слишком сложны. Гораздо более легкой и продуктивной средой оказалась Java, которая в то время быстро завоевывала позиции промышленного стандарта. Поэтому проект San-Francisco был переориентирован на Java.

San-Francisco — это серверный продукт, предназначенный для разработчиков, создающих Java-приложения для различных серверных ОС. Первоначально проект предназначался только для OS/400, но позднее был расширен для поддержки NT, AIX, HP/UX, OS/2 и MVS, а также Java (СК и ПК) и Windows.

Часть группы разработчиков San-Francisco работала в Рочестере, а часть — в Беб-лингене (Boeblingen), Германия. Рочестерцы отвечали за структуры низкого уровня и их встраивание в ОС. В Беблингене разрабатывали каркасы высокого уровня.

На рисунке 11.3 показаны три уровня каркасов San-Francisco. Базовый уровень взаимодействует с ОС через ВМ Java. Он управляет интерфейсами с ОС, другими приложениями, вводом-выводом и сетью, доступом к объектам, а также отслеживает последние. Базовый уровень также содержит классы объектов, из которых создаются объекты верхних уровней. Таким образом, базовый уровень скрывает сложности нижележащих структур от разработчика.

Рисунок 11.3. Каркасы Сан-Франциско

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

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

Некоторые авторы приложений используют только один или два нижних уровня, самостоятельно создавая общие деловые объекты или даже основные деловые процессы. IBM поощряет такую деятельность разработчиков — участников проекта San-Francisco.

Отдельные крупные разработчики приложений уже перешли на собственные объектные среды разработки и San-Francisco им не нужен. Основной рынок для этого проекта — множество средних и мелких создателей программ во всем мире. Так, большой интерес проявлен в Европе — ведь большинство средних разработчиков трудятся там. Многие из потенциальных заказчиков уже сотрудничают с нами в рамках координирующей группы San Francisco Advisory Group.

Далее мы рассмотрим две другие темы, связанные с поддержкой приложений: использование интегрированных ПК-серверов в качестве дополнительных процессоров приложений AS/400; и серверные модели AS/400.

В главе 10 мы говорили о том, как IOP и его специализированная ОС реального времени управляют устройствами. Управление устройствами было первоначальным, но не единственным назначением IOP. Так как IOP — это полноценные процессоры, которые могут поддерживать различные функции и даже различные ОС, то использование их IBM для других типов приложений было лишь вопросом времени. В последние несколько лет в AS/400 были введены IOP специального назначения, большего, нежели только поддержка устройств. На них возлагалась поддержка таких специфических функций как RAID-5, факс, беспроводные сети и AppleTalk. В связи с этим совершенно естественно дальнейшее использование таких IOP для выполнения и других типов приложений, включая серверные.

В 1994 году IBM объявила о первом серверном приложении, выполнявшемся на IOP, — FSIOP (File Server I/O Processor). FSIOP представлял собой плату удвоенной ширины, которая вставлялась в AS/400. На плате находился процессор Intel 486 и память для него. Другие устройства, включая диски, разделялись с AS/400. Плата FSIOP поддерживала один или два порта ЛВС из расчета до 255 пользователей на порт. Можно было подключать сети Token-Ring или Ethernet, причем в сервере AS/400 могло быть установлено нескольких таких плат.

На FSIOP работала ОС OS/2, хотя пользователи никогда не имели с ней дела напрямую. AS/400 управляла всеми взаимодействиями с OS/2; пользователю были видимы только приложения файл-сервера. Первым файл-серверным приложением, о котором мы объявили, был OS/2 LAN Server. Позднее к нему добавились NetWare и Lotus Domino.

Когда стало очевидно, что FSIOP можно использовать не только как файл-сервер, мы изменили его название на Integrated PC Server (IPCS) и позже создали новые модели IPCS с более мощными процессорами Intel Pentium и увеличенными объемами памяти. В версии 4 OS/2 была заменена Warp Server. Были добавлены и новые приложения, такие как Flowmark Workflow.

У IPCS внутри AS/400 много преимуществ. Во-первых, выполнение файл-серверных приложений перекладывается на выделенный процессор, что повышает общую производительность. Нет необходимости в отдельном ПК-сервере вне AS/400 — заказчик получает среду с единым сервером. AS/400 предоставляет файл-серверу интегрированную защиту, целостность и функции администрирования. Например, одна из поддерживаемых в IFS файловых систем, называемая QLANSrv, используется файл-сервером. С помощью простых команд данные перемещаются между разными файловыми системами. Кроме того, у файл-сервера есть доступ ко всем устройствам AS/400.

Недостаток отдельного файл-сервера ПК — необходимость иметь собственные диски. Если данные на сервере очень важны для пользователя, последний, несомненно, предпримет определенные меры, чтобы предохранить их. AS/400 может автоматически выполнять резервное копирование данных, на тот случай, если что-то случится с дисками сервера, но даже эта мера может оказаться недостаточной. Некоторые пользователи требуют особо устойчивой дисковой системы для защиты своих данных, а также гарантий, что работа не нарушится из-за сбоя диска. Для ПК-серверов доступны технологии зеркалирования дисков и RAID, а для достижения должного уровня безопасности могут быть установлены соответствующие программные пакеты.

Так что, по сути, проблема отдельного сервера ПК сводится к дублированию ресурсов. Так как в AS/400 уже реализована и технология зеркалирования дисков, и технология RAID, то явно имеет смысл использовать дисковые устройства AS/400. То же самое верно и для защиты. Одно из очевидных решений — поместить ПК «под крышу» AS/400 и предоставить ему доступ к ресурсам последней. Именно это и делает IPCS.

Использование IPCS в AS/400 вместо отдельного ПК-сервера дает дополнительные преимущества, если AS/400 и ПК-сервер располагаются на значительном удалении друг от друга. Предположим, что некто в удаленном подразделении добавил на сервер ПК новое приложение, что полностью исчерпало дисковое пространство на нем. Если на месте нет подготовленного персонала, то специалисту из головной организации нужно туда ехать, создавать резервную копию дисков, устанавливать диски большего объема и восстанавливать резервную копию. Если таких удаленных подразделений много, то затраты на командировки могут быть огромны. Но так как IPCS использует часть диска AS/400, то в центральном подразделении можно просто изменить объем дискового пространства, выделенного для IPCS.

Успех IPCS показал, что отдельные машины приложений «под крышей» AS/400 могут быть полезны заказчикам AS/400, не желающим иметь дела с отдельными ПК-серверами. IBM решила распространить концепцию машин приложений на другие серверные ОС, конкретно, на Unix и Windows NT.

Процессор приложений Unix мы впервые подготовили в начале 1997 для одного крупного заказчика, которому требовалось установить во множестве удаленных подразделений сервера как AS/400, так и Unix. (Позже процессор приложений Unix стал доступен и другим желающим.) Помещение сервера Unix под крышу AS/400 позволило этому заказчику содержать только одну систему в каждом подразделении и по-прежнему использовать приложения как AS/400, так и Unix. Интегрированный сервер Unix представляет собой плату, аналогичную IPCS. В отличие от IPCS, в сервере Unix применяется процессор PowerPC, а не Intel. ОС для этого интегрированного сервера служит AIX, версия Unix от IBM. Следует отметить, что интегрированный сервер AIX использует не только некоторые драйверы устройств AS/400, но также и собственные локальные устройства.

Другой пример интеграции полного сервера приложений в AS/400 — Windows NT на IPCS. В первой реализации используется процессор Intel Pentium Pro. Сейчас в качестве ОС используется Microsoft Windows NT Server 4.0, но в будущем возможна установка следующих версий этой ОС. В 1997 году IBM поставляла процессор приложений Windows NT лишь своим бизнес-партнерам, общедоступным он стал в начале 1998.

Так как на таком IPCS может выполняться любое приложение NT Server для процессора Intel, то IBM пришлось добавить некоторые локальные устройства, включая клавиатуру, мышь и дисплей. Таким образом, в отличие от оригинального IPCS, эта версия имеет разъемы для подключения локальных устройств. К этому серверу приложений можно подключать и другие адаптеры PCI. Некоторые устройства, такие как диски, компакт-диски и адаптеры ЛВС разделяются с AS/400. Для этой цели процессор приложений AS/400 использует драйверы устройств AS/400.

Чтобы Windows NT могла исполняться на разных аппаратных платформах, Microsoft определила так называемый слой абстрагирования от оборудования HAL (hardware abstraction layer). HAL — это слой кода, предназначенный для изоляции ядра ОС от аппаратных различий разных платформ. Например, HAL скрывает такие детали, как интерфейсы ввода-вывода, котроллеры прерываний и механизмы многопроцессорных коммуникаций. Вместо работы с этой аппаратурой напрямую, NT обращается к процедурам HAL.

Концептуально HAL напоминает MI, но на значительно более низком уровне. Так как большая часть процессоро-зависимого кода по-прежнему находится в ядре, Windows NT нельзя считать аппаратно-независимой. То же самое можно сказать и о приложениях NT, поскольку они компилируются непосредственно в двоичные коды конкретного процессора. Тем не менее, HAL позволяет обеспечить некоторую дополнительную интеграцию между процессором приложений NT и AS/400.

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

Файловая система NT (NTFS) размещается в байтовом пространстве OS/400. Пока отдельные файлы видимы только NT. Когда-нибудь, NTFS будет интегрирована в IFS, либо эти файлы станут «видимы» AS/400 с помощью какого-то другого механизма. Сегодня же для связи между этими двумя серверными ОС можно использовать ODBC.

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

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

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

В сентябре 1993 года мы представили первые серверные модели семейства AS/400. Новое семейство серверов AS/400 Advanced Server появилось в мае 1994 года и включало две модели — для мелких и средних фирм. В июне 1995 года были объявлены три новые серверные модели, позволившие занять весь рынок AS/400. Мы старались, чтобы они оптимально функционировали в качестве:

сервера базы данных;

сервера коммуникаций;

обработчика пакетных программ.

Все эти функции требуют большего объема вычислений, чем интерактивная обработка, и, соответственно, более высокой производительности по сравнению с традиционными моделями. Поэтому первоначально установили в младшие модели серверов высокопроизводительные процессы IMPI из старших традиционных моделей. Например, один или два процессора из старшей модели F70 (1993 год), выполненной в виде стоек, были использованы в меньших серверных моделях 135 и 140 соответственно. Мы также снабдили эти модели достаточным объемом памяти, дискового пространства и возможностями подключения к ЛВС для поддержки мощных процессоров в серверной среде. Эти процессоры значительно повысили производительность серверных приложений в сравнении с традиционными моделями. Работа сети, базы данных, файл-сервера и компиляторов также улучшилась. Появление RISC-процессоров, гораздо более производительных по сравнению с их предшественниками IMPI, позволило использовать одинаковые процессоры как в серверах, так и в традиционных системах.

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

Серверные модели AS/400 стали так популярны, что в е-серии мы решили расширить их диапазон и предложили рынку новые типы серверов. К этому нас побудили, в том числе, некоторые изменения в приложениях наших бизнес-партнеров. Например, многие из них теперь используют многоуровневую (multi-tier) клиент-серверную архитектуру. В трехуровневой архитектуре, клиенты ПК могут быть подключены к одному или нескольким выделенным серверам приложений, которые, в свою очередь, подключены к выделенным серверам базам данных. К серверам разных уровней предъявляются и разные требования. Поэтому теперь мы предоставляем своим заказчикам специально сконфигурированные мощные модели серверов приложений написанных бизнес-партнерами. С распространением AS/400 на другие среды появятся и новые специализированные модели е-серверов.

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

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

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

AS/400 оснащена первоклассной базой данных с очень широким диапазоном применения. На одном краю этого диапазона — системы AS/400 начального уровня, прямо конкурирующие с серверами и базами данных ПК. На другом — многопроцессорные конфигурации, объединяющие до 32 систем в кластере с помощью OptiConnect. Учитывая, что к каждой из таких систем можно подключить от одного до нескольких терабайтов дискового пространства, общий размер базы данных превосходит все, что только можно было вообразить себе несколько лет назад.

Ключевая и ближайшая задача IBM в этой области — повышение производительности базы данных (особенно SQL) на всем диапазоне систем. Вообще-то, «родной» интерфейс DB2/400 позволяет обеспечить более высокую производительность, нежели SQL, но поскольку все больше и больше приложений пишется для интерфейса SQL, то именно он — наша главная забота.

Другая проблема DB2/400 (как и любой другой базы данных) — обработка сложных типов данных, таких как объекты. При повсеместном переходе на использование распределенных объектов, база данных должна будет работать с этими абстрактными типами данных. Хотя крайне маловероятно, что кто-либо из основных производителей баз данных до конца столетия откажется от реляционной модели в пользу полностью объектно-ориентированной, все же нужно работать на опережение. Несмотря на то, что в данной области по-прежнему нет стандартов, организации типа OMG вносят предложения по методам хранения объектов или их компонентов в реляционной базе данных с возможностью выборки через систему управления объектно-ориентированной базой данных. IBM также рассматривает аналогичные предложения по базе DB2. Если эти предложения будут приняты, мы их реализуем.

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

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

Развитие старших моделей стало основным направлением наших работ в начале 90-х. Тогда многие наши крупные заказчики «уперлись в потолок» возможностей своих AS/400. Их требования к производительности и объемам системы превосходили то, что мы могли предоставить. Эти требования и подтолкнули нас к переходу на PowerPC. С появлением систем AS/400 на базе RISC-процессоров мы смогли на какое-то время удовлетворить потребности заказчиков в новых системах старшего уровня. Но спрос на еще большие объемы и производительность не уменьшился. Нашим ответом на растущие требования должны стать возможности моделей серии AS/400е. В этом разделе мы рассмотрим два метода, с помощью которых IBM планирует достичь намеченных высот производительности: одиночные системы и кластеры.

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

Кажется, я же упоминал, что люблю управлять гоночными автомобилями? Даже машина, на которой я езжу каждый день, заключает в своем двигателе Northstar (имя, которое мне всегда нравилось) 300 лошадиных сил. Мне не часто требуется столь мощный двигатель, чтобы добраться до своего офиса в IBM, но как приятно иногда «пощекотать своих лошадок» и убедиться, что все они проснулись! Так же преданно, как и мощные машины, я люблю мощные компьютеры. В моем домашнем ПК два процессора Pentium Pro. Разница в моей привязанности к мощным автомобилям и мощным компьютерам — это разница между спортивным интересом и деловой необходимостью.

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

Несколько лет назад производительность процессора для System/38 и ранних моделей AS/400 не считалась крайне важной. Мы шутили, что Pacific — кодовое название для System/38 — является сокращением от «Performance Ain't Critical if Function Is Complete»[ 83 ]. Мы сознательно жертвовали мощностью в пользу функциональности, зная, что, в конце концов, технологический прогресс приведет нас и к оптимальной производительности. Как показало время, такое решение было верным: сегодня у AS/400 есть и то, и другое.

К тому же ранние системы использовались для приложений интерактивной обработки, где производительность процессора менее важна, чем производительность ввода-вывода. В главе 10 мы рассмотрели, как на протяжении многих лет велась оптимизация AS/400 для достижения выдающейся производительности ввода-вывода.

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

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

Технология PowerPC лежит в основе повышения производительности для версии 4. (Этот процессор, а также все поколения 64-разрядных процессоров, которые разрабатывались или разрабатываются в Рочестере, подробно описаны в главе 2.) Мы использовали первое и второе поколения RISC-процессоров PowerPC в AS/400 в 1994 и 1995 годах. Системы версии 4 оснащены процессорами PowerPC третьего и четвертого поколений.

Производительность одиночного процессора важна для ПК, где процессор обрабатывает все вычисления и операции ввода-вывода. В таких системах нужны процессоры с высокими тактовыми частотами и большими кэшами. Однако для многопользовательских систем оптимально сочетание нескольких процессоров. Если требуется разделение памяти, как в большинстве коммерческих приложений, то наиболее эффективна модель SMP.

В главе 2 мы говорили, что слабое место большинства современных систем SMP — интерфейс памяти. Без эффективной системы памяти высокопроизводительные процессоры в конфигурации SMP по большей части простаивают в ожидании доставки данных.

Я очень люблю систему Cray CS6400, в которой 64 процессора использовали общую память с помощью четырех шин памяти, а не одной. Этот суперкомпьютер стоимостью в 4 миллиона долларов, предназначавшийся, кстати, для деловых приложений, использовал процессоры SuperSparc, тактовая частота которых — всего лишь 60 или 85 МГц. Высочайшая производительность достигалась этим компьютером не за счет высокоскоростных процессоров, которые большую часть времени простаивают, но за счет передового интерфейса памяти, регулирующего доступ процессоров к памяти.

Суперкомпьютер ASCI Option Blue Pacific — совместная разработка IBM и Министерства энергетики США — достигает высокой производительности за счет другой новейшей подсистемы памяти. В главе 2 рассматривалась и эта сама подсистема, и то, как ее версия используется в AS/400 для обеспечения производительности масштабируемых 8-ми и 12-процессорных конфигураций SMP. Несмотря на достаточно скромные возможности процессоров Apache второго поколения, эта подсистема памяти позволила компьютерам серии AS/400е достичь производительности в несколько раз выше, чем у ранних систем, оснащенных высокопроизводительными процессорами первого поколения Muskie. 12-процессорные системы с процессорами Apache сейчас могут поспорить по этому поводу с самыми крупными мэйнфреймами.

Мы планируем продемонстрировать промышленную модель самого мощного в мире суперкомпьютера в декабре 1998 года. Он использует новую реализацию подсистемы памяти процессоров Apache, что позволяет эффективно применять высокоскоростные процессоры даже в больших конфигурациях SMP.

Процессоры PowerPC четвертого поколения используют новую реализацию подсистемы памяти для достижения супервысокой эффективности. Эти процессоры могут поддерживать 16-канальные конфигурации. Четвертое поколение 64-разрядных процессоров PowerPC имеет различные уровни производительности, от 250 МГц до, примерно, 800 МГц. Не стоит и говорить, что мы ожидаем значительный рост общей производительности систем в течение следующих нескольких лет.

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

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

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

Если всех описанных расширений одиночных систем Вам мало, то можете объединить до 32 систем AS/400 в кластер. Кластер AS/400, несомненно, позволяет повысить производительность и емкость, но, что гораздо важнее, обеспечивает готовность вычислительной системы к работе 24 часа в день 7 дней в неделю. Одиночные системы таких гарантий дать не могут.

Кластеры были впервые использованы Digital Equipment Corporation как средство масштабируемости систем VAX. С течением времени кластеры завоевали популярность на рынках Unix и MVS, как средство обеспечения повышенной готовности. Появившиеся в последнее время заявления о поддержке кластеров в новых системах, таких как Windows NT, снова привлекли внимание к этой технологии. С перемещением деятельности большинства организаций в сетевой мир, который не спит никогда, требования к постоянной работе серверов обычны.

Впервые IBM предоставила самым крупным заказчикам AS/400 кластерную технологию OptiConnect в середине 1994 года. В главе 3 мы говорили, что сфера применения этого оптоволоконного продукта значительно расширилась за последние несколько лет. Например, поддержка параллельных слабо связанных баз данных позволила эксплуатировать такие приложения, как хранилища данных и сильно загруженные среды OLTP на очень больших системах. Сегодня в мире работает немало огромных конфигураций AS/400 с OptiConnect. Существует пример использования технологии OptiConnect для кластера AS/400, к которому подключено более 20 000 терминалов. Этот кластер обрабатывает почти миллион транзакций в час. Вот какими большими стали сейчас системы!

Как мы уже отмечали, кластеры OptiConnect служат не только для увеличения размеров системы, но и для поддержания постоянной готовности. Наши бизнес-партнеры легко добиваются высоких коэффициентов готовности системы, устанавливая на кластере AS/400 свои пакеты зеркалирования (репликации). Эти пакеты реплицируют данные и транзакции DB2/400 на несколько AS/400. AS/400 могут быть связаны с помощью OptiConnect или любой другой линии.

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

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

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

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

Средством соединения в петле SAN может быть либо медный провод, либо оптоволокно, в зависимости от расстояния между компьютерами. Оптоволокно оптимально на больших расстояниях. Очень большие скорости соединения SAN могут быть достигнуты, когда вместо последовательных оптических соединений станут использоваться параллельные. Разработчики Рочестера уже продемонстрировали параллельное оптико-волоконное соединение с 32 волокнами, работающее на частоте 500 МГц. Даже когда половина волокон используется для дублирования, производительность этого соединения равна 1 ГБ в секунду, что в 8 раз быстрее, чем производительность в 1 гигабит самой быстрой реализации OptiConnect. Конечно, так как SAN имеется только на самых новых системах и серверах AS/400е, OptiConnect еще несколько лет будет оставаться единственным средством объединения систем в кластер.

Можно с достаточной степенью вероятности предсказать этапы расширений поддержки кластеров с высокими параметрами готовности.

Сначала будет улучшена система удаленного журналирования и репликации объектов между системами для устранения всех единичных точек сбоя. Это повысит производительность и функциональные возможности пакетов зеркалирования и репликации наших бизнес-партнеров.

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

Третьим шагом будет обеспечение разделения базы данных между системами. В настоящее время IBM использует такую модель в System/390 Parallel Sysplex.

Механизм, поддерживающий как переключение, так и разделение дисков — независимые пулы вспомогательной памяти ASP (IASP), описанные в главе 8. ASP представляет собой набор дисковых устройств, в котором вся память пула выглядит одной непрерывной областью. ASP содержат различные системные объекты и применяются для оптимизации восстановления при сбоях дисков, изолируя эти сбои. Существуют один системный и до 15 пользовательских ASP.

IASP — специальная форма пользовательского ASP. Каждый IASP автономен, то есть, например, при выполнении загрузки системы IASP можно не подключать. Кроме того, IASP можно отключать, не останавливая всю систему. Задача в системе получает исключение, если пытается обратиться к объекту, находящемуся в отключенном IASP. IASP может быть подключен к одной или нескольким системам. IASP, подключенный к нескольким системам, рассматривается как ресурс кластера и может переключаться или разделяться между компьютерами кластера.

Идея создания IASP появилась в результате одной работы, проведенной возглавляемым мною отделом вскоре после объявления о выходе AS/400. Именно тогда Джим Рэнуайлер (Jim Ranweiler) исследовал способы создания кластеров AS/400 высокой готовности и пришел к концепции IASP. Мы положили эту работу на полку, пока она нам не понадобилась. Теперь, когда в наших планах — создание кластеров постоянной готовности, мы можем стряхнуть с этой работы пыль и использовать ее в AS/400.

Последняя тема этой главы — разработки аппаратных средств, предпринимаемые нами для дальнейшего улучшения соотношения цена — производительность (Ц — П) моделей серии AS/400е. За последние несколько лет наши клиенты стали свидетелями существенных улучшений в этой области. В е-серии это соотношение улучшилось примерно на 60 процентов по всем моделям, а для некоторых серверов — даже значительнее. В прошлом производительность и емкость системы улучшали без снижения цен, но чем дальше, тем больше соотношение Ц—П выходило на первый план. Сейчас цены быстро падают.

Я помню покупку своего первого ПК в 1982 году. В IBM была программа поддержки сотрудников, приобретавших в личное пользование первые IBM PC. В моей машине было 64К памяти и два 5-дюймовых дисковода (на тех первых ПК не было жестких дисков). Вместе с монохромным монитором и матричным принтером все это стоило мне 4 500 долларов. Сегодня за те же деньги я могу купить один из самых больших и мощных ПК. Я знаю это не понаслышке — я так и сделал. Но, конечно, я мог бы купить гораздо менее дорогой ПК, причем вполне приемлемой емкости и производительности.

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

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

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

Для современных серверов стандарты Ц—П устанавливает индустрия ПК. Серверы на процессорах Intel с Windows NT задали планку, которой приходится соответствовать всем остальным. Пока Ц—П серверов AS/400 весьма конкурентоспособна. Однако планка не фиксирована, она продолжает снижаться. Преимущество серверов ПК состоит в универсальной аппаратуре, используемой многими производителями. Для поддержания конкурентоспособности AS/400е также переходит на универсальную аппаратуру.

Наиболее очевидный знак этого перехода — помещение компьютеров е-серии в новые корпуса, такие же, как используются для RS/6000. Большая часть компонентов внутри корпусов также одинакова для обеих систем. Использование универсальных компонентов означает меньшую стоимость учета, складирования и даже самих компонентов из-за роста объемов производства. Такая универсальнность дала IBM возможность сократить производственных расходы, сконцентрировав все производство для AS/400 и RS/6000 в Рочестере и Санта-Паломбе (Santa Palomba), Италия.

Если заглянуть внутрь новых корпусов, мы увидим вновь разработанный CEC (Central Electronics Complex)[ 84 ]. CEC состоит из основных процессоров, основной памяти, источника питания и шин ввода-вывода. Ранее при переходе на выпуск новых и более быстрых моделей IBM эти компоненты обычно заменялись. Благодаря более эффективному СЕС теперь заказчик можете обойтись просто вставкой новых плат. Вновь разработанные корпуса предназначены для использования на все время существования версии 4, что должно сократить стоимость модернизации большинства моделей е-серии.

Но есть и модели, изначально не подлежащие модернизации, разработанные так специально для сокращения цены. Такой же подход используется на рынке ПК.

IBM привержена универсальной аппаратуре на всех своих платформах, что сокращает расходы на разработку и производство компонентов, общих для нескольких систем. Неполный список универсального оборудования включает процессоры, контроллеры памяти, системные шины, адаптеры ввода-вывода, источники питания и корпуса. Общие компоненты встречаются и в серии AS/400е: процессоры PowerPC, системные шины 6хх, адаптеры PCI и соединения SAN. Результатом всей этой деятельности станет дальнейшее улучшение показателя Ц—П.

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

IBM приняла на вооружение новую архитектуру SSA (Serial Storage Architecture), которая уже начала появляться в различных системах корпорации. Стандарт этой архитектуры разработан Американским национальным институтом стандартов ANSI (American National Standards Institute). SSA определяет высокопроизводительное последовательное соединение для подключения устройств ввода-вывода. Данное соединение было оптимизировано для устройств хранения данных, таких как жесткие диски, платы хост-адаптеров, и контроллеры дисковых массивов. Первые дисковые подсистемы SAA были созданы IBM в 1996 году.

У SSA много преимуществ перед существующими параллельными интерфейсами, такими как SCSI (Small Computer Systems Interface) по ключевым параметрам: производительности, возможностям подключения, надежности. Кроме того, она использует более компактные кабели и разъемы. Для поддержки миграции и совместного использования SAA сохраняет значительную часть логического протокола SCSI-2.

Использование SSA в последующих выпусках версии 4 для е-серии снизит стоимость подключения дисков и повысит производительность. Типичная конфигурация кольца с одним хост-адаптером может обеспечить пропускную способность до 73 МБ в секунду, и в будущем эта скорость повысится. Физическим средством соединения может быть либо медный кабель длиной до 20 метров, либо оптоволокно — для больших расстояний.

Последовательная связь выигрывает по сравнению с существующими параллельными интерфейсами. Более дешевые и малоразмерные кабели и разъемы хорошо подходят для маленьких 3,5- и 2,5-дюймовых дисков, причем к одному хост-адаптеру можно подключить больше устройств. Увеличение производительности дает и дуплексное соединение с устройствами. Чтобы повысить надежность, используется не простая проверка четности на шине, а CRC. Наконец, на последовательной линии легче и дешевле осуществлять переключение, что станет особенно важно, когда в AS/ 400 будут реализованы переключаемые и разделяемые диски для кластеров с постоянной готовностью.

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

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

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

Алгоритм сжатия IBMLZ1 был разработан так, что обеспечивает не только очень эффективное сжатие, но и весьма высокую надежность[ 85 ]. Это важно потому, что сжатие убирает из исходных данных избыточность, делающую их весьма уязвимыми для разрушения. IBM достигла высокой надежности технологии сжатия посредством комбинированного использования технологии КМОП для микросхемы и взаимосвязанной схемы проверки упаковки — распаковки, при которой CRC оригинальных данных сравнивается с CRC распакованных данных. Еще раз подчеркну, все это осуществляется микросхемой без потери производительности операций чтения и записи с диска!

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

нагрузки на шины ввода-вывода. Описанная технология сжатия будет использоваться во всех будущих дисковых адаптерах.

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

Мы живем в «эру WWW», где длина года — три месяца. Изменения происходят так быстро, что теперь наши циклы разработки мы измеряем в «годах WWW». Теперь Вам ясно, почему в версии 4 будет так много выпусков? Тогда не удивляйтесь, что в следующие несколько лет произойдут новые изменения, причем такие, какие сегодня даже трудно предсказать. Таков наш бизнес.

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

Примечания:

8

Аббревиатура API используется (в том числе, и в оригинале книги) в двух значениях: интерфейс прикладных программ в целом и отдельная функция интерфейса прикладных программ. Во втором значении API может употребляться во множественном числе: в английском — APIs, в русском, естественно, без изменения. — Прим. переводчика.

80

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

81

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

82

Если считать, что Microsoft входит в группу основных производителей программных средств (а так считает, пожалуй, большинство), то нужно заметить, что упомянутая корпорация так и не приняла стандарт Java (по состоянию на ноябрь 1997 года). — Прим. консультанта.

83

«Производительность не критична, если обеспечена функциональность». — Прим. переводчика.

84

CEC — это то, что обычно называют системным блоком. — Прим. консультанта.

85

Если Вы хотите узнать больше о сжатии данных вообще и об алгоритме IBMLZ1 в частности, я рекомендую Вам новую книгу Роя Хоффмана—Roy Hoffman. Data Compression in Digital Systems. Chapman & Hall. 1997.