Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 35 (всего у книги 41 страниц)

Поддержка приложений

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

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 ]81
  «Java Beans» – буквально «зерна Java». Как уже упоминалось, язык, получивший потом название Java, изначально предполагалось использовать для управления бытовой техникой – магнитофонами, кофеварками и т. п. Поэтому на иллюстрациях к описаниям Java часто изображают кофеварки или чашечку кофе. Кстати, название Java совпадает с названием популярного сорта кофе. – Прим. консультанта.


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

Главное достоинство Java в том, что он принят всеми основными производителями аппаратных и программных средств[ 82 ]82
  Если считать, что 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). Основная цель его создания – сделать открытую, не зависящую от платформы объектную модель, которая будет использоваться разными языками и ОС. Последняя версия стандарта – 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 года, включает встроенные потоки, значительно повышающие общую производительность системы.

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

В 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.