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.
