Версия 4

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

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

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

Расширенная версия 4 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Как Вы помните, подход электронного бизнеса к прикладным решениям состоит в сочетании систем и процессов, выполняющих базовые операции, с простотой и доступностью, обеспечиваемыми современными технологиями Интернета и WWW.. Эти инвестиции отражают предполагаемые направления развития компьютерной индустрии в соответствии с нуждами наших заказчиков в течение нескольких следующих лет. Они также указывают на те расширения, которые Вы можете ожидать в 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, расшифровывались и пояснялись в лекции 7 при обсуждении защищенного сервера WWW. Некоторые из этих пояснений я повторю. Мы не будем подробно рассматривать каждый компонент, а лишь постараемся оценить широту диапазона функций AS/400 для обслуживания Интернета и интранетов. Важно отметить, что и новые, и существующие приложения поддерживают выход в сетевой мир. Итак:

Клиенты 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 (pointtopoint protocol). В качестве ЛВС могут использоваться TokenRing, 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 стал для этих пользователей наилучшим сервером.

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

Сервер группового ПО объединяет пять компонентов, соответствующих этим видам деятельности в интегрированную среду. Например, когда компонент АДП определяет, что в некий процесс должен быть вовлечен дополнительный сотрудник, сервер может для уведомления сотрудника воспользоваться компонентом электронной почты. Добавьте к этому поддержку 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 представляет собой единый интегрированный пакет, куда входят средства поддержки:

Новые расширения семейства 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, Java везде и всюду

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

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

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

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

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

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

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

Главное достоинство Java в том, что он принят всеми основными производителями аппаратных и программных средствЕсли считать, что Microsoft входит в группу основных производителей программных средств (а так считает, пожалуй, большинство), то нужно заметить, что упомянутая корпорация так и не приняла стандарт Java (по состоянию на ноябрь 1997 года). — Прим. консультанта.. Программирование на этом языке часто характеризуют так: "Пишется однажды — исполняется всегда". Разработчики, создавая программу на одной машине 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 настолько широко распространился, что имеет реальные шансы стать доминирующим языком объектноориентированного программирования, заменив С++.

Java для AS/400

Мы, разработчики новых версий 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). Основная цель его создания — сделать открытую, не зависящую от платформы объектную модель, которая будет использоваться разными языками и ОС. Последняя версия стандарта — CORBA2 — позволяет старым приложениям, написанным на С++ и Smalltalk, взаимодействовать с Java, а также облегчает их перенос на Java.

В соревновании производителей за объектную модель, которая станет стандартом для всей индустрии, лидируют Java и Microsoft СОМ, тогда как OMG CORBA2 — на третьем месте, то есть отстает. Будущее стандарта 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 года, включает встроенные потоки, значительно повышающие общую производительность системы.

Проект San Francisco (Каркасы Java)

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

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

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

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

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

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

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

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

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

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

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