эта технология становится все совершенней и более пригодной для коммерческого применения. Важную роль в этом процессе играют партнеры создателя Java компании Sun Microsystems. И одну из ключевых позиций на рынке Java занимает столь хорошо знакомая россиянам корпорация Inprise (ранее Borland). Именно ее продукт JBuilder задает тон в создании среды разработки для программистов, избравших Java своим орудием производства.

Достигнув успеха на вертикальном рынке средств разработки Java, компания Inprise начинает наступать на рынок горизонтальный, связанный с применением Java-продуктов в деловой сфере. Первым шагом в этой области смело можно считать пакет Borland Deployment Server for Java, назначение которого состоит в создании централизованного хранилища готовых приложений Java на сервере и запуске этих программ по мере поступления запросов от компьютеров-клиентов. В настоящий момент Deployment Server for Java (DSJ)- составляющая часть Borland JBuilder Client/Server Suite. Однако, по последним данным, DSJ начинает продаваться как самостоятельный продукт.

Основная идея DSJ - сделать загрузку приложений Java с сервера такой же, как загрузка аплета Java с Web-сервера. Отличие Java-приложения от Java-аплета состоит в том, что ограничений доступа к ресурсам хост-компьютера у приложений нет, да и выбор инструментов API будет побогаче.

Перечислим рабочие объекты DSJ:

  • пользователь (user) - человек, обращающийся к DSJ за сервисом; характеризуется именем и паролем;
  • группа доступа (access group) - группа пользователей и IP-адресов, имеющих одинаковые для сервера права доступа к приложениям; IP-адреса нужны для жесткого определения клиентских мест, с которых происходит обращение к серверу DSJ;
  • сервер (server) - компьютер, на котором установлена серверная часть DSJ;
  • группа серверов (server group) - несколько серверов, объединенных логически для упрощения установки одного и того же приложения сразу на несколько серверов.

    Установка DSJ состоит из трех этапов: установка серверной части, установка клиентской части и конфигурация обеих составляющих. Серверную и клиентскую части DSJ следует рассматривать отдельно.

    Сервер DSJ

      
    Рис. 1. Центр управления DSJ
    На сервернyю часть Deployment Server for Java падает основная работа, поскольку это и хранилище запускаемых на клиентских компьютерах приложений, и база данных пользователей и рабочих групп, и репозитарий для хранения библиотек времени исполнения, и - что самое главное - это централизованный пульт управления всеми перечисленными выше составляющими. Примечательно, что можно выстраивать систему из нескольких серверов. В этом случае администратор может размещать разные Java-программы по разным серверам, устанавливать сложные конфигурации доступа, что дает поистине неограниченные возможности в области реализации безопасных и удобных информационных проектов.

    Интерфейс серверной части Deployment Server for Java - это одна диалоговая панель с тремя закладками (рис. 1).

      
    Рис. 2. Каждая фаза процесса взаимодействия между клиентом и сервером регистрируется
    Окно закладки Console служит для показа сообщений, посылаемых сервером администратору. Как правило, это информация о том, что сервер проделал какое-то действие или возникла некоторая нештатная ситуация. На второй закладке, Events, сервер показывает все события, шаг за шагом регистрируемые в процессе работы сервера. В этом окне администратор может найти подробные сведения о программах, запущенных пользователями, и о том, что в этот момент происходило (рис. 2).

    И наконец, третья закладка, Connections, показывает в окне текущие соединения между клиентскими компьютерами и сервером (рис. 3).

      
    Рис. 3. Оперативная сводка с "места боевых действий"
    Управление сервером DSJ-администратор осуществляет из окна, в котором перечислены все рабочие объекты, имеющиеся в информационной системе. Именно отсюда своей твердой рукой системный администратор определяет статус пользователей, серверов, групп, а заодно управляет приложениями и библиотеками. К примеру, он может временно запретить использование какой-нибудь программы, скажем, по техническим причинам: если он намерен установить на сервер новую ее версию или, обновив версию среды времени исполнения Java (JRE), хочет сделать ее доступной для клиентских компьютеров. Короче, что бы ни делал администратор, он делает это именно в окне управления сервером (рис. 4).

      
    Рис. 4. Ресурсы DSJ как на ладони
    Чтобы понять, как работает DSJ, следует проследить, что же происходит в процессе старта сервера и обработки им запросов от машин-клиентов. Рис. 5 иллюстрирует этот процесс.

    Загрузившись, сервер DSJ начинает сканировать каталоги, содержащие различные версии сред времени исполнения Java (JRE), включающие в себя виртуальную машину Java, библиотеки времени исполнения и различные файлы настройки (фаза 1). Если в процессе работы находятся неупакованные JRE, они пакуются в архивы для удобства пересылки. Далее в память считываются имена и пароли пользователей, настройки групп доступа, группы серверов, индекс базы данных пакетов Java. И в завершение стартового процесса подгружается информация обо всех установленных на сервер приложениях (фаза 2). С этого момента сервер готов к обслуживанию клиентов.

    Получив запрос от клиента (фаза 3), сервер проверяет, сколько одновременных соединений ему разрешено поддерживать и, если максимум достигнут, прощается с клиентом, отказав ему в обслуживании. Если все в порядке, то от клиента к серверу пересылается информация, авторизующая пользователя и имя запускаемой Java-программы (фаза 3). Если клиент не послал имя требуемой программы, то сервер вышлет ему список всех имеющихся на сервере приложений. Когда пользователь клиентского компьютера выбрал нужную программу, посылается еще один запрос серверу, который может сопровождаться информацией об имеющейся на компьютере-клиенте версии JRE (фаза 4). Сервер определяет, подойдет ли она для запуска программы, и если нет - посылает клиенту требуемый для корректной работы вариант JRE, после чего клиентская часть JRE перезапускается и делает повторный запрос к серверу. И теперь, если соединение удовлетворяет всем требованиям, клиенту пересылаются файлы затребованного приложения (фаза 5), после чего производится старт Java-программы на клиентской стороне (фаза 6). Конечно, это весьма и весьма упрощенная схема работы, но она дает общее представление, как осуществляется взаимодействие в среде Deployment Server for Java.

    Клиент DSJ

      
    Рис. 6. Клиент DSJ
    Клиентская часть Deployment Server for Java служит мостиком между пользователем компьютера, "заказывающим музыку", и сервером, ее играющим. С точки зрения пользователя, клиентская часть DSJ выглядит как диалоговая панель со списком приложений Java, доступных для запуска (рис. 6).

    Клиент DSJ, будучи запущенным, загружает специальный Java-класс borland.jax.client.Jax, выполняющий основную работу (фаза 1). Из файла свойств dsj.properties получаются необходимые параметры, которые ранее были определены либо системным администратором, либо пользователем (фаза 2). Если была выбрана программа, запускаемая по умолчанию, первичному серверу посылается запрос на нее, после чего клиент, получив файлы этой программы, приступает к ее выполнению. В противном случае пользователь получает на экране список всех доступных ему приложений Java. Когда происходит выбор конкретной программы, первичный сервер присылает клиенту список всех серверов DSJ, на которых имеется запрошенная Java-программа (фаза 3). Опросив все перечисленные серверы, клиентская машина либо находит среди них подходящий, и последний передает файлы требуемой программы (фаза 4), либо на экране появляется сообщение о невозможности запуска выбранного пользователем приложения. Отказ может быть вызван различными причинами. Например, один сервер выключен в это время, другой не обрабатывает запросы для выбранной программы или же отказывает в обслуживании данному компьютеру с определенным IP-адресом по причинам обеспечения безопасности.

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

    Зачем все это?

    У некоторых читателей вполне может сложиться впечатление, что Deployment Server for Java - все тот же бег на месте, которым сейчас заняты многие производители программного обеспечения. На самом же деле появление DSJ - очень сильный технологический рывок в мире Java. В DSJ отчетливо видны все признаки клиент-серверных систем с репликацией кода и данных, т. е. именно того, к чему стремится корпоративный рынок информационных технологий. Управление DSJ - это работа, которая без преувеличений по плечу даже "чайникам". Да и замена ПО делается в один прием. Достаточно инсталлировать новые программы на сервер, как они тут же станут доступны всем клиентским машинам (разумеется, тем, у кого есть соответствующие привилегии). Похоже, Sun может выдвигать новый лозунг "Write Once, Deploy Everywhere" (напиши один раз, разверни повсюду) по аналогии с известным "Write Once, Run Everywhere" (напиши один раз, запускай повсюду).

    Однако новое, ради чего, собственно, все и затевалось, состоит в том, чтобы управлять приложениями централизованно, как это сейчас происходит с аплетами. Только вместо аплетов DSJ оперирует обычными приложениями, "умеющими" гораздо больше, да и выполняющимися намного быстрее. Это очень мощное решение, вполне сравнимое с законом, известным в техническом прогнозировании как получение бисистемы со сложением полезных функций и нейтрализацией вредных. Если смотреть и далее в этом направлении, становится ясно, что существование аплетов как самостоятельного вида приложений после появления Borland Deployment Server for Java вообще можно поставить под сомнение. Тем более что для обеспечения безопасности - а это одна из главных функций аплетов, изначально жестко "прошитая" в Java, - уже имеются такие методы, как цифровые подписи и задание политики безопасности. Причем последний метод активно продвигается в JDK версии 1.2.

    Не исключено, что Deployment Server for Java может стать переломной точкой в "кофейной", с позволения сказать, технологии.