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