Опыт внедрения Java-технологии в компании Sun Microsystems

Инфраструктура

Java и тонкие клиенты

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

Установка программного обеспечения связана с индивидуальным подходом к каждому клиенту. Пользователь может с легкостью установить ПО, которое сделает его машину частично или полностью неработоспособной. Резервное копирование пользовательских данных также требует учета специфики каждой системы. В результате увеличивается вероятность того, что копирование выполняется от случая к случаю или не выполняется совсем.

В модели тонкого клиента пользовательские данные, приложения, даже загружаемый образ операционной системы и ее конфигурация хранятся на сетевых серверах.

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

Модель тонкого клиента обладает рядом достоинств:

• Клиентскую систему не нужно администрировать, поскольку она не содержит внутреннего диска. Вся информация о состоянии клиента хранится на сервере.
• Для обновления версии операционной системы достаточно поместить ее на локальный сервер и перезагрузить клиентские машины.
• Клиентские системы могут быть дешевле традиционных настольных, поскольку они не нуждаются во внутреннем диске и большом объеме оперативной памяти.
• Отказавшее устройство можно заменить так же просто, как и телефонный аппарат, поскольку не нужно реконфигурировать клиентскую систему или загружать на нее программное обеспечение. Новая машина включается в сеть, и пользователь может продолжать работу.
• Тонкие клиенты с поддержкой Java могут воспользоваться достоинствами мобильного ПО с простой схемой распространения приложений через Web.
• В традиционной модели толстого клиента требуется полная загрузка приложений. В модели тонкого клиента приложения могут разрабатываться на языке Java помодульно, с загрузкой каждого модуля только в случае необходимости. Это упрощает и удешевляет распространение и поддержку приложений.

Вебтоп

Что такое вебтоп?

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

В конфигурации, развернутой в компании SUN Microsystems, пользовательский интерфейс обслуживают навигатор HotJava и пакет HotJava Views.

Поддерживающий сервер хранит информацию о состоянии и данные каждого пользователя. В качестве сетевых устройств, обеспечивающих доступ к настольной среде (вебтоп-устройств), могут использоваться Java-станции или SPARC-системы. Пользователям предоставлены типичные настольные утилиты, включая индивидуальные инструменты и корпоративные Интранет- и Интернет-приложения.

Пользовательский вебтоп должен быть доступен с любого вебтоп-устройства, входящего в основной NIS-домен пользователя. Это означает, что пользователь может воспользоваться любым вебтоп-устройством в NIS-домене и попасть в свою привычную среду (с точностью до имеющихся аппаратных отличий). В будущем планируется реализовать пользовательский доступ с любого вебтоп-устройства, подключенного к глобальной сети компании.

Программа Webtone

По аналогии с телефонией, где работоспособность телефонного аппарата подтверждается непрерывным гудком в трубке (dialtone), компания SUN Microsystems использует термин "вебтон" (webtone, "сетевой гудок") для обозначения готовности устройств к работе в компьютерной сети. Коротко говоря, смысл программы Webtone состоит в том, чтобы любое устройство с сетевым интерфейсом получило доступ в Web. Для тонких клиентов, таких как JavaStation, вебтон обеспечивается загрузкой операционной системы по сети, а для персональных компьютеров и рабочих станций — наличием сетевого доступа. Программа Webtone рассчитана не только на компьютеры, но также на телефоны и другие одно- и многофункциональные устройства.

Постоянная работоспособность телефонов воспринимается нами как нечто само собой разумеющееся, хотя телефонным компаниям приходится создавать и поддерживать сложную инфраструктуру. Вебтон требует сетевой и серверной инфраструктуры. Задача состоит в том, чтобы скрыть внутреннюю инфраструктурную и эксплуатационную сложность, предоставив пользователям простой и надежный сервис.

Инфраструктурные сервисы

Определения

Главный сервер программного обеспечения — выделенный компьютер, содержащий основную, авторизованную версию вебтоп-приложений и конфигурационных данных.

Сервер пользовательских вебтопов — сервер, на котором выполняются все вспомогательные процессы.

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

Сервер программного обеспечения — сервер, хранящий все Java- и X-приложения.

Вебтоп-клиент - пользовательская Web-среда, реализованная на таких системах, как JavaStation и SPARC Solaris.

Сервер начальной загрузки - сервер, обеспечивающий загрузку Java-станций по сети.

Главный сервер начальной загрузки — выделенный компьютер, содержащий основную, авторизованную версию JavaOS.

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

Вебтопам требуется поддерживающая инфраструктура, поскольку большинство сервисов они получают с удаленных серверов. Инфраструктура должна предоставлять следующие сервисы:

• начальная загрузка;
• конфигурирование пользовательской среды;
• агентские сервисы, сервисы кэширования;
• распространение приложений и доступ к ним;
• вычислительные сервисы;
• сервисы каталогов;
• доступ к пользовательским данным.

Инфраструктура будет управляться высокоавтоматизированным, централизованным способом. Большинство сервисов будут администрироваться из центрального пункта управления и распространяться по соответствующей иерархии.

Системная среда функционирует следующим образом:

• Java-станция загружается с сервера начальной загрузки данной подсети;
• Java-станция запрашивает у пользователя входное имя и пароль и проверяет их соответствие с NIS-каталогом;
• Java-станция загружает HotJava Views с сервера пользовательских вебтопов;
• Пакет HotJava Views обеспечивает интерфейс к почте, календарю и навигатору, а также к эмулируемой X-среде;
• Доступ ко всем Java-приложениям осуществляется из навигационной среды или с домашней страницы пользователя;
• Аплеты и вспомогательное серверное программное обеспечение располагаются на сервере ПО и предоставляются серверам вебтопов с помощью NFS-монтирования;
• Аплеты и приложения запускают вспомогательные серверные процессы на серверах вебтопов, а интерфейсные компоненты — на Java-станциях. Для сервероцентрических приложений вспомогательные процессы запускаются на ассоциированном сервере (глобальном или региональном).
• Доступ ко всем Java-приложениям осуществляется с помощью навигатора и аплетов. Выделяется центральный (или региональный, чтобы учесть местную специфику) универсальный локатор ресурсов, обратившись по которому пользователи смогут запустить любое допустимое приложение.
• Аплеты могут загружаться локально с сервера вебтопов; возможна и переадресация запроса (реализуемая сервисом переадресации) на ассоциированный сервер приложений.

Описанная инфраструктура представлена на Рис. 1.

Начальная загрузка Java-станций

Java-станции не содержат внутренних дисков, поэтому необходимо, чтобы в состав подсети входил сервер начальной загрузки. При включении Java-станции сервер должен обеспечить передачу операционной системы и ее конфигурирование.

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

Начальная загрузка, обслуживаемая сервером, разбивается на следующие этапы:

• Java-станция передает RARP-запрос для получения своего IP-адреса.
• Java-станция передает широковещательное TFTP-сообщение вторичной программе начальной загрузки (inetboot.jd).
• Программа inetboot.jd передает широковещательный запрос RPC BOOTPARAMS, чтобы определить файловую систему сервер:маршрут.
• Программа inetboot.jd выполняет NFS-монтирование (только на чтение) файловой системы сервер:маршрут.
• Из файловой системы сервер:маршрут читается и начинает выполняться загрузочный образ /kona.
• Из загрузочного образа /kona извлекается и начинает выполняться ядро JavaOS.

JavaOS передает DHCP-запрос, чтобы определить:

• IP-адрес Java-станции;
• маску сети;
• сетевой шлюз;
• имя DNS-домена;
• IP-адрес DNS-сервера;
• имя NIS-домена;
• имя сервера времени;
• часовой пояс;
• аргументы начальной загрузки JavaOS.

• JavaOS подключается к NIS-домену.
• На экране Java-станции появляется входное окно JavaOS.
• Пользователь вводит входное имя и пароль, зарегистрированные в NIS-домене.
• В NIS-каталоге auto_home ищется элемент, соответствующий входному имени пользователя; если поиск оказался успешным, выполняется NFS-монтирование домашнего каталога пользователя.
• Главная программа (Selector) пакета HotJava Views извлекается из ранее загруженного образа /kona и начинает выполняться.
• Программа Selector загружает аплеты и другие компоненты HotJava Views, используя универсальный локатор ресурсов (URL), полученный в ответе на DHCP-запрос как часть аргументов начальной загрузки JavaOS.

Конфигурация подсистемы начальной загрузки

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

Пока Java-станция конфигурируется для выполнения начальной загрузки с одного сервера. В будущем появится возможность поддерживать для Java-станции несколько серверов начальной загрузки.

Загружаемый образ и конфигурационная информация для Java-станций распространяется на серверы выделенным главным сервером начальной загрузки.

Сервер начальной загрузки

Каждый сервер начальной загрузки должен быть сконфигурирован для выполнения следующих функций:

• обслуживание RARP-запросов для определения сетевой конфигурации;
• обслуживание передачи по протоколу TFTP;
• выдача информации о параметрах начальной загрузки в ответ на запрос RPC.BOOTPARAMS;
• доступ на чтение по протоколу NFS к загружаемому образу JavaOS;
• обслуживание конфигурационных DHCP-запросов.

Протоколы, используемые в процессе начальной загрузки

• RARP/DHCP. RARP используется имеющейся аппаратурой JavaStation для выяснения основных элементов сетевой конфигурации. В будущем планируется полностью перейти на DHCP.
• TFTP. TFTP используется для передачи образа JavaOS с сервера начальной загрузки.
• BOOTPARAMS. Протокол RPC BOOTPARAMS используется для выяснения расположения образа JavaOS вебтопа.
• NFS. Каталог, содержащий образ JavaOS вебтопа, монтируется только на чтение по протоколу NFS для получения загрузочного образа /kona.

Распространение JavaOS

Распространение JavaOS интегрируется с инфраструктурой автоматической установки AutoInstall (Solaris JumpStart). Система AutoInstall разработана в SUNIR для упрощения начальной загрузки по сети в корпоративной среде. Поддержка Java-станций реализуется как часть программного обеспечения AutoInstall.

Главный сервер начальной загрузки JavaOS будет совпадать с главный сервером инфраструктуры AutoInstall. Загрузочная среда JavaOS будет доставляться на все серверы AutoInstall/Boot корпоративной сети с использованием дерева распространения AutoInstall.

Сервер пользовательских вебтопов

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

Каждый сервер вебтопов предоставляет следующие сервисы:

• HTTP-доступ к аплетам HotJava Views;
• HTTP-доступ к прикладным аплетам;
• сервис HTTP-переадресации к серверам приложений;
• выполнение пользовательских приложений и их серверных компонентов;
• выполнение унаследованных X-приложений;
• начальная загрузка Java-станций (для небольших подразделений, где на одном сервере объединены сервис начальной загрузки и поддержка вебтопов);
• доступ к домашним каталогам (которые должны быть смонтированы по NFS на чтение/запись).

Сервер вебтопов будет многоцелевым:

• На сервере вебтопов будет выполняться HTTP-сервер, обеспечивающий загрузку приложений HotJava Views; это придаст ему статус доверенного сервера.
• На сервере вебтопов будут установлены клиентоцентрические аплеты. Сервер будет обеспечивать вспомогательные функции для этих аплетов (доступ к домашним каталогам, локальным принтерам и т.п.).
• На сервере вебтопов будут устанавливаться доверенные аплеты, имеющие доступ к домашним каталогам (смонтированным на вебтоп-клиентах) и к другим серверам.
• Сервер вебтопов будет поддерживать X-приложения, выполняемые с использованием X-эмулятора.
• Сервер вебтопов будет предоставлять также сервис переадресации, обеспечивая единообразный доступ ко всем аплетам.

Клиентоцентрические и доверенные аплеты будут храниться на сервере вебтопов или в файловых системах, доступных серверу через NFS-механизм. Аплеты будут интегрированы со вспомогательными серверами. Когда подобный пакет устанавливается на сервере вебтопов, там же происходит запуск вспомогательного сервера, который либо сам обслуживает всех клиентов, либо инициирует необходимые процессы для каждого из них.

Агентские/кэширующие серверы

Вебтоп-клиенты, как и другие Web-устройства, конфигурируются в расчете на использование обычной инфраструктуры агентских/кэширующих Web-серверов. Помимо прочего, эти серверы будут обеспечивать кэширование сервероцентрических аплетов.

Распространение программного обеспечения

В данном разделе объясняется, для чего нужна инфраструктура распространения аплетов в Интранет.

В корпоративной сети SUN в настоящее время зарегистрировано около 20 тысяч пользователей и 30 тысяч настольных систем. Каждый пользователь должен загрузить аплеты, чтобы начать их выполнение на своем вебтопе. Имеется два способа распространения аплетов:

• предварительное перенесение аплетов на близкий к клиенту сервер;
• загрузка аплетов с центральной системы.

Каждый из двух способов хорош в определенных обстоятельствах, поэтому поддерживаться должны оба.

Требования

К механизму распространения аплетов предъявляются следующие требования:

• пользователи должны иметь возможность доступа к аплетам из известных мест Интранет;
• должно поддерживаться как получение аплетов по запросу, так и их принудительное распространение;
• инфраструктура должна обеспечивать работу серверов второго уровня на серверах аплетов, поскольку аплет может взаимодействовать только со "своим" сервером;
• должна поддерживаться синхронизация версий аплетов и вспомогательных серверов;
• инфраструктура должна обеспечивать распространение новых версий и эффективное внесение изменений в существующие версии;
• инфраструктура должна поддерживать распространение не-Java-приложений, чтобы обеспечить однородность механизмов распространения;
• архитектура должна быть гибкой, допускающей интеграцию будущих технологий.

Существующая модель распространения программного обеспечения (Softdist)

Существующая модель распространения программного обеспечения включает более 400 систем, распределенных по корпоративной сети SUN. Серверы Softdist объединены в иерархическую структуру, представленную на Рис. 2.

Процесс распространения начинается с главного сервера. Через промежуточный уровень программное обеспечение попадает на серверы нижнего уровня, где происходит процесс установки. Конечные пользователи осуществляют доступ к серверам Softdist по протоколу NFS.

Система Softdist включает пять видов инструментов:

• средства подготовки пакетов программного обеспечения;
• средства распространения пакетов;
• менеджер клиентского доступа;
• менеджер доступа к программному обеспечению;
• средства регистрации использования ПО.

Опишем перечисленные инструменты подробнее.

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

• перечень аппаратных и программных платформ, на которых пакет может работать;
• список доступных команд и маршрутные имена выполнимых файлов;
• переменные окружения, необходимые для работы пакета.

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

• список серверов Softdist, на которые необходимо доставить пакеты;
• время, когда должно быть выполнено распространение;
• статус пакетов после распространения.

Менеджер клиентского доступа предоставляет единообразные методы доступа к пакетам на серверах Softdist. Используя характеристики, заданные поставщиком, менеджер формирует необходимое окружение и выбирает выполнимые файлы, соответствующие клиентской платформе.

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

Средства регистрации использования ПО дают конечным пользователям возможность отслеживать применение определенных пакетов и сохранять накопленную информацию в центральной базе данных. Эта информация полезна для переговоров с производителем о количестве лицензий и для системного администрирования.

Будущая модель (Webdist)

Рис. 3 иллюстрирует будущую архитектуру серверов распространения программного обеспечения Webdist. Для простоты показан только один главный сервер. Будем предполагать, что мы не собираемся распространять сервероцентрические аплеты на региональные серверы вебтопов. С главного сервера Webdist будут распространяться только клиентоцентрические аплеты и ассоциированные вспомогательные сервисы, упакованные в единый пакет.

Для сервероцентрических аплетов необходимо распространять сервер переадресации и ассоциированные данные. Эти данные могут изменяться на главном сервере переадресации и распространяться в регионы с помощью главного сервера Webdist.

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

Эволюция инфраструктуры Softdist

Для перехода к будущей модели требуются лишь незначительные модификации инфраструктуры Softdist. Сервер вебтопов может стать элементом иерархии распространения или монтировать файловые системы серверов Softdist для доступа к аплетам, вспомогательным сервисам и таблицам переадресации (см. Рис. 4).

Инфраструктура Softdist используется для доставки пакетов на серверы Softdist, файловые системы которых монтируются серверами вебтопов (впрочем, возможно и объединение серверов). На серверах Softdist могут поддерживаться данные, новые версии программного обеспечения, заплаты и т.п., то есть большая часть распространяемой информации.

Главный сервер программного обеспечения

Главный сервер программного обеспечения содержит аплеты HotJava Views, клиентоцентрические аплеты и конфигурационную информацию вебтопов. Соответствующие файлы передаются по дереву распространения и в конце концов становятся доступными каждому серверу вебтопов.

Главный сервер ПО предоставляет конфигурационную информацию, позволяющую клиентам осуществлять с вебтопов доступ к аплетам. На каждом сервере вебтопов эта информация подвергается локализационной настройке. В частности, возможно расширение набора приложений с учетом местной специфики.

Частью распространяемой конфигурационной информации являются универсальные локаторы ресурсов для сервероцентрических приложений. В результате клиенты вебтопов получают единообразный доступ через HotJava Views ко всем аплетам и приложениям.

Серверы выполнения

Серверы выполнения обеспечивают следующие сервисы:

• выполнение серверов приложений и сервлетов;
• выполнение X-приложений;
• HTTP-сервис для аплетов HotJava;
• HTTP-доступ к локальным приложениям/аплетам;
• HTTP-переадресацию для других HTTP-серверов, содержащих приложения/аплеты;
• начальную загрузку Java-станций (там, где это необходимо).

Серверы выполнения масштабируются в соответствии с объемом обслуживания (от подсети до группы зданий или даже региона).

Сервисы каталогов

Необходимо несколько различных сервисов каталогов. В будущем могут использоваться сервисы LDAP (Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам) и NIS+. В текущей версии JavaOS поддерживаются сервисы NIS, DNS и DHCP.

Для JavaOS требуется следующая информация, предоставляемая сервисом NIS:

• аутентификационная информация из каталогов passwd.*;
• расположение домашних каталогов пользователей (NIS-калатог auto_home);
• список доступных принтеров (NIS-калатог printers.conf).

NIS-сервис может предоставлять любой сервер в подсети, в том числе сервер вебтопов.

DNS-серверы поддерживают соответствие между именами и IP-адресами компьютеров.

DHCP-сервис предоставляется каждым сервером начальной загрузки Java-станций (см. выше раздел "Начальная загрузка Java-станций").

Сервис переадресации

Сервис переадресации нужен для того, чтобы предоставить пользователям единообразный доступ ко всем аплетам, независимо от их расположения. Этот сервис основывается на протоколе HTTP, в котором сервер может отвечать на URL-запрос сообщением о переадресации и новым локатором ресурсов.

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

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

Вебтопы направляют запросы сервису переадресации. Соответствующий URL имеет вид http://сервер_переадресации/имя_аплета. Сервис отвечает новым локатором ресурсов, который используется вебтопом в новом запросе.

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

Доступ к пользовательским данным

Каждый пользователь приписывается к определенному серверу данных, предоставляющему следующие сервисы:

• хранение домашних каталогов пользователей. Домашний каталог должен быть доступен для NFS-монтирования на чтение/запись с сервера вебтопов и со всех вебтоп-устройств пользовательского NIS-домена.
• хранение почты, передача почты, доступ к почте по протоколу IMAP4.
• хранение календарных данных и доступ к ним.

В будущем планируется дать пользователям возможность осуществлять подключение с помощью любого вебтоп-устройства, расположенного в произвольной точке корпоративной сети компании.

Пользовательский интерфейс

Основным интерфейсом пользователей вебтопов является HotJava Views. Через Views предоставляется доступ к почте, календарю, службе каталогов и навигатору HotJava (см. Рис. 5).

Java-аплеты будут доступны через центральные/региональные наборы локаторов, которые сами задаются с помощью URL. Каждый пользователь имеет в сети свою домашнюю страницу, разделенную на общую и персональную части.

Компонент Mail View предоставляет доступ к почтовой системе в стандарте IMAP4.

Компонент Calendar View обеспечивает интерфейс с сервером Solaris Calendar Manager.

Name View служит для доступа к информации о сотрудниках компании и других людях. Пользователи Name View могут выполнять SQL-запросы.

Native Java Apps — это интерфейс для запуска "родных" Java-приложений.

Пользователи могут входить в серверы вебтопов, и аплет X-Emulator обеспечит настольную среду, аналогичную той, что реализована в ОС Solaris. С помощью X-Emulator можно запускать все существующие X-приложения, что облегчает переход на новую архитектуру.

Разработка

Трехуровневая архитектура

Введение

Трехуровневая архитектура, ставшая нормой для приложений, разрабатываемых Управлением информационных ресурсов компании SUN Microsystems (SUNIR), пока распространена гораздо меньше, чем двухуровневая.

Мы рассмотрим эту архитектурную модель, остановимся на некоторых вопросах разработки и развертывания трехуровневых приложений, дадим некоторые рекомендации.

Обзор архитектуры

Трехуровневое приложение состоит из следующих компонентов:

• Интерфейсный (обычно графический) компонент представляет первый уровень. В настоящее время он должен быть реализован как аплет, выполняемый в среде HotJava Views. Первый уровень не должен иметь прямых связей с базой данных и хранить состояние приложения.

На втором уровне располагается сервер приложений. Это может быть программная система, написанная на Java или C/C++. Обычно на второй уровень выносят:

• сервис удаленного вызова методов JavaRMI;
• работу с сокетами;
• объектный сервис JOE/NEO (см. [1], раздел "Java, Joe, NEO" — прим. перев.);
• сервлеты Java Web-сервера

• На втором уровне сосредоточена большая часть прикладной логики. Вне его остаются фрагменты, экспортируемые на клиентские системы, а также погруженные в третий уровень хранимые процедуры и триггеры.

• Третий уровень обеспечивает хранение данных. Обычно это стандартная реляционная или объектно-ориентированная СУБД.

Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

Мы не рекомендуем концентрировать выполнение всех логических компонентов приложений на втором уровне. Во время работы некоторые фрагменты могут импортироваться с сервера и выполняться на первом уровне. К числу таких фрагментов принадлежат:

• средства редактирования и проверки входных полей;
• средства проведения несложных операций с данными, уже присутствующими на клиентской системе, и некоторые другие.

Достоинства трехуровневой архитектуры

Основными преимуществами трехуровневой архитектуры по сравнению с двухуровневой являются:

• масштабируемость;
• конфигурируемость;
• возможность модификации бизнес-логики;
• многократное использование сервисов.

Масштабируемость

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

Еще один момент связан с ограниченными ресурсами памяти существующих Java-станций. Традиционный двухуровневый подход рассчитан на значительно большие клиентские ресурсы, необходимые для выполнения логических фрагментов приложений. При трехуровневой архитектуре большая часть прикладной логики переносится на второй уровень.

В двухуровневой архитектуре сервер СУБД должен поддерживать соединения со всеми активными клиентами. Такой подход приемлем только для небольших приложений с ограниченным числом пользователей, его невозможно промасштабировать до корпоративных размеров в силу внутренних ограничений на количество серверных соединений. Трехуровневая архитектура существенно увеличивает масштабируемость, поскольку каждый компонент второго уровня может мультиплексировать множество соединений с клиентами в одно соединение с сервером СУБД.

Конфигурируемость

Трехуровневая архитектура облегчает управление конфигурацией, поскольку клиенты изолированы от третьего уровня. В случае выхода из строя сервера СУБД достаточно произвести простое переконфигурирование серверов второго уровня, не затрагивая клиентские системы.

Возможность модификации бизнес-логики

Трехуровневая архитектура позволяет концентрировать бизнес-логику на втором уровне и модифицировать ее, не затрагивая многочисленные и зачастую разнородные клиентские системы.

Многократное использование сервисов

После развертывания сервисов второго уровня их можно сделать доступными другим приложениям, снижая тем самым затраты на разработку и администрирование.

Проектирование

Разработке и развертыванию приложений с трехуровневой архитектурой предшествует решение ряда вопросов проектирования, на которых мы и остановимся.

Файловый сервис и сервис печати

Во многих приложениях требуется доступ к файлам и возможность вывода информации на печать, однако использование этих сервисов в описываемой среде наталкивается на определенные трудности, связанные с моделью безопасности Java и с отсутствием долговременной памяти на клиентских системах первого уровня, в роли которых выступают Java-станции. Решение состоит в том, чтобы предоставить клиентам связь с агентами, для которых упомянутые сервисы доступны.

Почтовый сервис

Почтовый сервис, который также требуется многим приложениям, предоставляется навигаторами (Netscape Navigator и HotJava), используемыми в компании SUN Microsystems.

В тех случаях, когда требуется более продвинутое решение, можно использовать программный интерфейс почтового клиента HotJava Views, хотя при этом и возникают определенные технические трудности.

Управление и мониторинг

Трехуровневая архитектура нуждается в новых средствах управления и мониторинга, способных помочь в выявлении и устранении проблем. Вместо двух процессов (клиент и сервер СУБД) будут существовать по крайней мере три: клиент, сервер второго уровня и сервер СУБД. В навигационной прикладной среде добавление HTTP­-сервера увеличивает число процессов до четырех. Применение механизмов JavaRMI и JOE/NEO невозможно без дальнейшего возрастания количества процессов.

В результате, при возникновении каких-либо проблем, выявить их причину становится непросто, особенно если учесть распределенность процессов по различным компьютерам и по разным областям корпоративной сети.

В число новых средств входят:

• инструментарий удаленного управления/мониторинга;
• командные процедуры автоматического перезапуска процессов.

Проектирование трехуровневых приложений должно включать выбор протокола удаленного администрирования/мониторинга. Добавить поддержку подобного протокола после того, как приложение разработано и/или развернуто, значительно сложнее.

Информационная безопасность

Любое приложение должно поддерживать некоторый защитный протокол, способный разграничивать доступ к сервисам. В трехуровневой архитектуре необходимо позаботиться о безопасности сервисов второго и третьего уровней.

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

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

На первый взгляд кажется, что описанная схема надежно защищает от несанкционированного доступа, однако это не так. Всякий, знающий серверный программный интерфейс, может получить доступ к базе данных через сервер второго уровня, не проходя процедуру аутентификации. Это верно, в частности, если на втором уровне используются механизмы JavaRMI или JOE/NEO, поскольку серверный интерфейс можно выяснить, например, средствами рефлексии (см. [4], раздел "Афиширование и выяснение интерфейсов" — прим. перев.).

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

В трехуровневой архитектуре необходимо защищать не только базу данных, но и серверы второго уровня. Этого можно добиться, если предоставлять доступ к объектной ссылке на сервер второго уровня только авторизованным клиентам, успешно прошедшим процедуру идентификации/аутентификации.

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

Трехуровневая архитектура позволяет централизовать процедуру аутентификации и авторизации при доступе ко второму уровню и использовать стандартный протокол аутентификации между первым и вторым уровнями.

Пользователям нужно будет помнить единственную комбинацию "входное имя/пароль", а накладные расходы на администрирование входных имен на втором уровне значительно снизятся. Пользователи смогут чаще менять пароли, упростится процедура смены паролей после нарушений безопасности. Деактивацию пользовательских входов после увольнения сотрудников можно будет проводить централизованно.

Архитектура с заверенными аплетами

Введение

Управлению информационных ресурсов следует принять и реализовать архитектуру с заверенными аплетами. Это позволит избежать многочисленных сложностей, связанных с учетом ограничений, накладываемых виртуальной Java-машиной и менеджером безопасности на потенциально ненадежные аплеты.

Для реализации архитектуры с заверенными аплетами следует организовать сертификационный центр и отработать процедуры заверения аплетов и распределения ключей.

Предложение

Одна из принципиальных трудностей при проектировании, реализации и распространении Java-аплетов и ассоциированных серверов приложений связана с ограничениями безопасности, накладываемыми на загруженные (и, следовательно, ненадежные) аплеты. Таким аплетам запрещен доступ к системным ресурсам (сокетам, файлам), они не могут запускать процессы и т.п. Более точно, аплету разрешается открывать соединение через сокет или механизм RMI только с тем хостом, откуда аплет был загружен. Следовательно, аплет не сможет открыть сокет, чтобы принять соединение с произвольного хоста, что делает невозможным функционирование RMI-объектов на клиентской стороне.

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

В среде разработки JDK 1.1 появилось понятие заверенных аплетов, которые навигатор HotJava считает надежными, предоставляя им неограниченный доступ к ресурсам.

Для заверения аплетов и проверки их аутентичности можно использовать стандартную структуру сертификационных центров и известные механизмы распространения ключей. Заверяться могут JAR-файлы, хранящие одно или несколько приложений.

Литература

1. Александр Таранов , Владимир Цишевский -- Java как центр архипелага -- Jet Info, 9, 1996
2. Java-стратегия компании SUN Microsystems -- Jet Info, 1996, # 21-22
3. Операционная среда Sun Solaris -- Jet Info, 1997, # 15
4. Владимир Галатенко , Александр Таранов -- Компонентная объектная модель JavaBeans -- Jet Info, 1997, # 19

Конференция Java-разработчиков

С 7 по 10 сентября 1997 года в Чикаго состоялась конференция, посвященная применению языка Java для разработки приложений самого разного масштаба — от программ, встроенных в предметы бытовой электроники, до корпоративных комплексов приложений. Докладчики рассказывали о собственном опыте использования Java при построении информационных систем нового поколения.

Спонсорами конференции были четыре компании — Sun Microsystems, IBM, Microsoft и GemStone. Отметим, что в этих компаниях сосредоточено более половины всех разработок, связанных с Java.

В течение четырех дней состоялось девять технических сессий, мини-выставка компаний-участников, а также различные презентации и круглые столы, проходившие во время, свободное от выступлений.

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

На конференции, а в дальнейшем и на выставке, работало до 30 компаний, специализирующихся в области информационных технологий.

Представленные фирмы можно разделить на два типа — разработчики инструментальных средств, поддерживающих Java и CORBA, и компании консультационные, разработчики проектов, специализирующиеся на применении новых технологий и инструментальных средств. К первой группе относятся такие компании, как Sun, IBM, Microsoft, Rational, GemStone, ко второй — I-Kinetiks, Icon Computing, Alta Software и др. Компании первого типа замечательны тем, что формируют новые технологии: Java, JavaBeans, UML, ODBMS. Компании второго типа интересны своим умением использовать эти новые технологии, что является общей проблемой системных интеграторов и разработчиков программного обеспечения. Со специалистами из подобных фирм — докладчиками, представителями, работающими на выставке, — обсуждались в первую очередь вопросы построения реальных надежных систем обработки транзакций, а также проблемы работы с заказчиками, количество заказов и т.п.

Суммируя впечатления от переговоров с техническими специалистами из компаний-разработчиков проектов, можно сделать следующие выводы:

• В настоящий момент проекты, связанные с использованием новых технологий — Java, CORBA, распределенные трехзвенные системы, Интранет — составляют 15-20% от всех новых разработок, ведущихся этими компаниями или их заказчиками.
• Количество таких проектов растет в экспоненциальной зависимости.
• Нынешние разработки — это в основном пилотные проекты, в некоторых случаях уже перерастающие в промышленные и внедряющиеся в деятельность предприятий.
• Практически все проекты поражают грандиозностью будущего размаха, однако сегодня речь идет о реализации лишь части задуманных систем.
• Являясь максимум пятой частью от всех разработок, эти проекты требуют большого количества специалистов и больших капиталовложений. В компании Alta Software ориентировочно говорили, что стоимость подобных проектов как минимум в 2.5 раза выше, чем обычных, с учетом привлечения одинакового количества разработчиков.
• Наиболее популярным и пользующимся спросом видом деятельности является обучение новым технологиям — разного рода тренинги, курсы, семинары. Консалтинговые компании зарабатывают на этом больше половины всех средств.
• В большинстве проектов планируется создать высоконадежные транзакционные системы. Правда, в тех частях, которые реализованы сейчас, нет ни одного примера надежной обработки транзакций (имеются в виду реальные системы, а не средства разработки), однако их добавление планируется в ближайшем будущем.
• Все соглашаются с необходимостью использования стандартов при разработке крупных систем. При этом в реализованных сейчас компонентах соответствие этим стандартам зачастую отсутствует, но постулируется, что далее разработка будет вестись в соответствии с какой-либо спецификацией.

Необходимо отметить, что в целом все технологии, которые использовались при разработке проектов в компании Jet Infosystems, хорошо коррелируют с теми, которые применяются в западных проектах. Методы построения распределенных систем, архитектурные принципы, инструментальные средства — все соответствует общемировым решениям, современному уровню и тенденциям развития.

Несколько докладчиков в своих выступлениях наглядно рассказали о реальных разработках распределенных систем на Java и CORBA для различных вертикальных рынков — медицинского, финансового, торгового. Ими давались четкие и детальные рекомендации по методике и технологии разработки Интранет-приложений. Важным фактором является успешное внедрение двух рассмотренных на конференции проектов в сферах медицинского обслуживания и продажи автомобилей. Эти проекты принадлежат к числу первых завершенных систем, подтверждающих правильность применения новых технологий.

Bradley Green, представитель компании Alta Software, описал полную архитектуру информационной системы, обслуживающей дилерскую сеть фирм, продающих автомобили. Внедрение этой системы, обеспечивающей возможности дистрибуции и оформление заказов в оперативном режиме, а также позволяющей покупателям производить расчеты через Интернет, увеличило эффективность продаж более чем в полтора раза.

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

Общая архитектура разработанного Интернет-доступа показана на Рис. 1.

Подобная архитектура типична для большинства разрабатываемых корпоративных Интернет/Интранет-систем. Многие ведущие компании, включая Sun, IBM, Microsoft, Rational и др., полагают, что будущее принадлежит сходным архитектурам, и создают средства разработки, обеспечивающие их поддержку. Эти компании фактически определяют информационные технологии, которые будут доминировать в течение ближайших лет. Очень важен тот факт, что инструментальные средства для Java разрабатываются практически всеми ведущими фирмами. Это позволяет утверждать, что Java-технология принята как новое средство разработки приложений и построения информационных систем.

Анализируя выступления в дебатах и на круглых столах, можно сделать вывод, что компании по-разному относятся к Java. В основном спор сводится к тому, является ли Java просто новым языком программирования, или это технология, применимая к разным областям информатики и способная изменить сегодняшние представления о компьютерных системах. Одним из главных сторонников языка Java, как новой технологии, естественно, является Sun Microsystems. Sun — компания, разработавшая Java, сделала эту технологию своим стратегическим направлением. В рамках корпорации Sun создано несколько дочерних компаний, основным элементом деятельности которых является Java.

Так, фирма Javasoft ведет большинство проектов, связанных с разработкой программного обеспечением на Java, — графических инструментальных сред, трансляторов, прикладных систем. Недавно Sun приобрела французскую компанию Chorus, специализирующуюся на производстве программного обеспечения для бытовой техники, средств связи и другой электроники (см. [1] и [2]). С помощью этой фирмы Sun надеется использовать Java во множестве повсеместно применяемых электронных приборов.

IBM — второй сильнейший сторонник Java. IBM также воспринимает Java, как новую технологию, и в полной мере способствует ее продвижению. Сегодня более 200 продуктов поддерживают Java, в том числе общеизвестные средства разработки семейства VisualAge. Примечателен тот факт, что IBM рассматривает Java как основное средство конкурентной борьбы с Microsoft. В IBM даже создан специальный институт, который так и называется, — "Институт конкурентной борьбы с Microsoft".

Сама корпорация Microsoft также называет себя сторонником Java, упорно и последовательно отстаивая свою позицию в этой области.

Корпорация Microsoft рассматривает Java исключительно как новый язык программирования, который, как говорят ее специалисты, имеет свои достоинства и недостатки. Microsoft выпускает средства разработки с поддержкой Java, однако, к сожалению, его продукты делаются несовместимыми с остальными операционными средами. Так, например, продукт Visual J++ генерирует Java-код, который может выполняться только виртуальной машиной от Microsoft. Выступления представителей Microsoft на конференции еще раз подчеркнули обособленность позиции корпорации в мире Java.

В частности, Microsoft не собирается поддерживать спецификацию Java RMI, обеспечивающую взаимодействие распределенных объектов, так как имеет собственную технологию DCOM.

Другие компании, имеющие достаточную известность в мире программных разработок, в основном поддерживают Java как новую технологию. GemStone, лидер в области объектных СУБД, в последних версиях продукта обеспечивает доступ к хранимым объектам средствами Java.

Rational, ведущий разработчик объектных CASE-средств, уже имеет продукты из семейства Rational Rose с генерацией кода на Java. Компания Iona Technologies, которая лидирует в области создания CORBA-совместимых продуктов, также поддерживает Java-технологию и уже разработала продукт OrbixWeb, являющийся реализацией брокера объектных запросов для Java.

В конференции участвовало около 200 человек более чем из 20 стран, что, несомненно, свидетельствует об огромном интересе, проявляемом к Java. Большинство участников придерживалось мнения, что Java является именно новой технологией, а не просто очередным языком программирования. Присутствие на конференции компаний, работающих в различных сегментах рынка, показывает, что Java интересна реальным пользователям будущих систем.

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

Другим направлением развития является новая объектная компонентная среда JavaBeans (см. [1]). Эта спецификация конкурирует с технологией Microsoft DCOM. JavaBeans, однако, поддерживается целым рядом компаний и, что более важно, рассматривается вопрос о стандартизации JavaBeans как компонентной среды в рамках консорциума OMG (на сегодня принятым стандартом является OpenDoc, но в силу различных нетехнических причин эта спецификация не смогла доказать свою работоспособность). JavaBeans развивается очень быстро. Встроить поддержку JavaBeans в свои средства разработки обещают в ближайшем будущем несколько компаний, в числе которых Symantec, IBM, Microsoft. На конференции теме JavaBeans было посвящено много выступлений, что свидетельствует о большом интересе к этой среде. По результатам обсуждений можно сказать, что JavaBeans — еще очень молодая технология и, соответственно, имеет определенные недостатки. На ее основе нет еще готовых приложений, но потенциал ее роста чрезвычайно велик.

Следующим направлением развитием Java является технология взаимодействия распределенных объектов в сети. Фактически, в Java определена новая архитектура, получившая название Java RMI (Remote Method Invocation — удаленный вызов методов). Эта архитектура отличается от хорошо известных сегодня CORBA и DCOM. Java RMI включает в себя определенные элементы, существующие в каждой из этих технологий. Консорциум OMG также развивает эту архитектуру и дополняет последнюю спецификацию CORBA 2.0 новыми элементами из RMI.

Еще одним очень перспективным направлением представляется аппаратная поддержка Java. В первую очередь следует упомянуть сетевые компьютеры или Java-терминалы. Кроме того, Sun планирует разработать (и уже разработал — см. заметку "Объявлен первый микропроцессор семейства microJava" в этом же номере Jet Info) специальные Java-процессоры, исполняющие команды виртуальной Java-машины. Эти процессоры предполагается встраивать в бытовую электронику, средства связи, системы обработки пластиковых карточек и т.п.

По результатам общения со специалистами компаний-разработчиков инструментальных средств прослеживаются следующие тенденции:

• Все компании, включая Microsoft, признают компонентную среду JavaBeans и собираются создавать инструментальные средства с поддержкой этой спецификации.
• Технологии CORBA и Java интегрируются и в сумме заполняют те пробелы, которые есть в каждой из них. Предполагается, что следующая версия спецификации CORBA будет включать основные принципы, заключенные в распределенной модели вычислений в языке Java, то есть будет поддерживать Java RMI. Сделано это будет путем модификации протокола IIOP с добавлением в него новых возможностей.
• Ожидается, что методология, разработанная компанией Rational, — Unified Method на основе языка моделирования Unified Modeling Language — в ближайшее время будет принята консорциумом OMG как стандарт для моделирования распределенных систем.

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

Литература

• Владимир Галатенко , Александр Таранов -- Компонентная объектная модель JavaBeans
• Материал компании Bay Networks -- Создание сетевой инфраструктуры Интранет

Опыт внедрения Java в крупных компаниях

Любую технологию оценивают не по рекламным словам, а по реальным делам. Попробуем проанализировать уже довольно обширный опыт разработки и внедрения Java-приложений в информационных системах крупных компаний.

Корпорация CSX

Корпорация CSX является одной из крупнейших транспортных компаний США. Она владеет сетью железных дорог, портовыми терминалами, осуществляет комплексное транспортное обслуживания с доставкой грузов в более чем 70 стран мира.

Одна из главных задач, которую ставит перед собой CSX, - улучшение качества обслуживания клиентов путем предоставления им возможности удаленного доступа для размещения заказов и отслеживания их выполнения. Для этой цели была разработана клиентская "транспортная рабочая станция" (TWS) на платформе ПК и OS/2. Прикладное ПО для нее было написано на языке С. Используя TWS, клиент может получить доступ к информационным ресурсам CSX.

Идея TWS оказалось очень эффективной с содержательной точки зрения, однако ее внедрение сдерживалось высокой стоимостью эксплуатации и управления персональными компьютерами на клиентских рабочих местах.

В Web- и Java-технологиях специалисты CSX увидели возможность по-новому реализовать идею удаленного клиентского доступа. Работа над новой концепцией, получившей название TWSNet, началась в 1996 году. Требовалось обеспечить поддержку внутренних операций компании и целый спектр сервисов для клиентов.

TWSNet построена в трехуровневой архитектуре, причем уровень представления и прикладной уровень написаны на Java. Большая часть Java-кодов для TWSNet размещена на втором уровне, где они служат для доступа к CGI-процедурам и базе данных, расположенной на мэйнфрейме. Уже первый этап внедрения TWSNet подтвердил готовность Java для применения в ответственных приложениях.

Создание первой очереди TWSNet, предназначенной для управления транспортировкой грузов по железным дорогам, заняло 90 дней и стоило миллион долларов. В штаб-квартире CSX серверная часть TWSnet работает на выделенном сервере Sun UltraSPARC 170, к нему подключены Java-станции с навигатором HotJava. Информация хранится в базе данных Oracle, которая также работает на сервере UltraSPARC, связанном с мэйнфреймом IBM 9000. Пятнадцать основных, наиболее крупных клиентов CSX получили доступ к TWSnet с использованием ПК и навигаторов, поддерживающих Java.

CSX оценивает годовую эффективность внедрения Java-вычислений в 5 миллионов долларов, но главный эффект состоит в более полном удовлетворении запросов пользователей.

Опыт эксплуатации первой очереди TSWNet позволяет сделать прогноз, что в течение ближайших двух лет принципы Java-вычислений будут распространены на все сферы деятельности компании. За это время CSX предполагает приобрести примерно 10 000 Java-станций.

CSX намеревается предложить свой опыт использования Java Американской Ассоциации Железных Дорог для выработки новых отраслевых стандартов информационных технологий.

Scottish Telecom

Основанная в 1994 году, компания Scottish Telecom (ST) относится к числу наиболее быстро развивающихся компаний Великобритании. За три года ST смогла войти в список пятидесяти крупнейших компаний Объединенного Королевства.

Старт "с нуля" позволил ST выбрать бизнес-стратегию и используемые информационные технологии, не обременяя себя грузом прошлого. Требования к информационной системе вытекают из маркетинговой стратегии ST, которая основана на трех основных позициях:

• Агрессивная ценовая политика. Стоимость услуг должна обеспечить преимущество перед конкурентами.
• Высокое качество обслуживания. Клиент должен решать все проблемы (от первичного подключения до вопросов оплаты), взаимодействуя только с одним представителем компании.
• Адаптация к требованиям клиента.

После исследования возможных вариантов в ST приняли решение об использовании Java в качестве базиса информационной системы. Менеджер ST Норри Крэйг комментирует этот шаг следующим образом: "Мы провели испытание нескольких конкурирующих подходов и пришли к выводу, что только компания Sun с ее Java-вычислениями в состоянии удовлетворить наши требования в части гибкости и масштабирования. Мы не использовали ActiveX, поскольку стремимся сохранить открытость системы и независимость от типа платформ."

Информационная система ST построена в трехуровневой архитектуре. Все приложения, осуществляющие взаимодействие с другими системами, написаны на Java. Компонентная модель Java позволяет отделить функциональные аспекты от бизнес-логики, что гарантирует практическую возможность модернизации продуктов и сервисов. Она обеспечивает также доступ большому числу пользователей к внешней сети ST. Существенно и то, что Java позволяет осуществлять централизованное управление информационными ресурсами.

Начиная свою работу в 1994 году, ST была вынуждена временно использовать персональные компьютеры. Последовавший затем процесс замены ПК Java-станциями, определяемый высокой стоимостью и сложностью обслуживания рабочих мест на ПК, уже на первых этапах продемонстрировал преимущества тонких клиентов. Практически нулевая стоимость обслуживания Java-станций дала основание для приятия решения о полной замене ПК Java-станциями на более чем 1000 рабочих местах.

Анализ существующих готовых программных решений показал что, ни одно из них не удовлетворяет требованиям к открытости системы, предъявляемым ST. Компания хотела иметь свободу действий, поэтому было принято решения о самостоятельной разработке программного обеспечения на Java. Ограничение по времени было достаточно жестким. Набранная команда программистов, имеющих опыт работы на C++, за три месяца реализовала первую версию программного продукта. На создание полнофункциональной системы ST потребовалось пять месяцев.

British Telecom

British Telecom (BT) — одна из крупнейших в мире телекоммуникационных компаний, ей принадлежит примерно 80% рынка телекоммуникационных услуг в Великобритании.

Отделение National Business Communications (NBC) непосредственно отвечает за взаимодействие с клиентами. Один из новых видов сервиса NBC, получивший название ServiceView, предоставляет пользователям непосредственный доступ к ресурсам BT, позволяя им подписываться на новые каналы или отказываться от части сервиса, сообщать о возникших проблемах, получать счета в электронной форме, просматривать свою платежную историю и многое другое.

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

В 1996 году руководство BT пришло к выводу о том, что перевод ServiceView на Java-технологию может стать решением возникших проблем.

Конкретная форма взаимодействия клиента с BT теперь зависит от объема потребляемых услуг связи. Крупные корпоративные клиенты, затраты которых на услуги связи превышают 1.5 миллиона долларов, могут иметь специально выделенные рабочие места на "тонком клиенте" и постоянно контролировать процесс взаимодействия с BT. Корпоративные клиенты с меньшим потреблением услуг могут использовать ПК и навигаторы, поддерживающие Java-аплеты. В перспективе BT намеревается распространить применение Java-технологии на основную массу потребителей.

С целью проверки принятых решений пилотный вариант Java-версии ServiceView был протестирован BT совместно с полицейскими органами.

Специалисты BT считают, дальнейший прогресс может быть достигнут за счет применения продуктов Joe и NEO, а также программного обеспечения промежуточного слоя.

SABRE Group

SABRE — лидирующая компания в области информационного обеспечения перевозки пассажиров и туристического бизнеса. Она владеет самой большой в мире частной компьютерной системой, работающей в режиме реального времени. В сеть SABRE включено свыше 130 000 терминалов, расположенных в компаниях-перевозчиках и туристических агентствах, ее услугами пользуются крупнейшие авиационные компании и компании по прокату автомобилей. Информационный центр, расположенный в городе Талса (Оклахома), обрабатывает в день до 190 миллионов сообщений. Он построен на основе 17 мэйнфреймов с общей производительностью, превышающей 4000 MIPS, а массив дисковой памяти имеет объем 15.3 Тб.

Доступ с клиентских мест, подключенных к системе SABRE, обеспечивает продукт QIK Access, разработанный в 1990 году, написанный на C++ и работающий под управлением Windows, DOS или OS/2. За годы эксплуатации QIK Access доказал свою надежность и эффективность. Рассмотрев возможности Java-вычислений, специалисты SABRE пришли к выводу о том, что переход на Java-технологии позволит увеличить число клиентов, подключаемых к сети, сохранив все достоинства QIK Access и не требуя больших затрат на перепрограммирование.

Поскольку QIK Access построен на принципах трехуровневой архитектуры с разделением функций пользовательского интерфейса, прикладной логики и доступа к базам данных, то достаточно переписать на Java интерфейсные компоненты. Использование единого Java-ядра для разных типов платформ позволит упростить поддержку удаленных пользователей. В условиях динамичного бизнеса возможность централизованного распространения приложений обеспечивает значительные преимущества. При использовании приложений на C++, работающих на ПК, обновление ПО превращается в трудоемкий и длительный процесс. С переходом на Java модернизация приложений сводится к обновлению ПО всего на нескольких серверах.

Процесс создания приложений на Java прошел в SABRE быстро и безболезненно. С помощью двух прикомандированных опытных Java-программистов из Sun Microsystems полнофункциональная бета-версия системы резервирования авиабилетов была создана за несколько дней, а всего на реализацию Java-версии QIK Access потребовалось шесть недель.

Поставляемая сегодня Java-версия QIK Access на JavaStation, по мнению специалистов SABRE, обладает большей гибкостью, надежностью и намного дешевле, чем версия на ПК.

American Information Systems

Область деятельности компании American Information Systems (AIS), основанной в 1992 году, — построение бизнес-систем средствами Интернет. AIS разрабатывает приложения для электронных каталогов, размещения заказов и доступа к хранилищам данных. Новая разработка AIS — мощная система для телеконференций с использованием WWW. После анализа возможных инструментальных средств, которые должны отвечать таким требованиям, как межплатформная совместимость, интуитивно понятный пользовательский интерфейс и взаимодействие в режиме реального времени, AIS выбрала Java в качестве языка программирования и среды разработки.

Используемые сейчас средства для телеконференций требуют значительных инвестиций в аппаратуру. В AIS приняли решение о создании продукта, который позволит организовывать телеконференции в частных сетях и в WWW с минимальными затратами на аппаратное обеспечение. Компания разработала продукт Forum, включающий клиентское ПО и соответствующее серверное приложение. Разработчики Forum считают, что Java — это единственное средство, используя которое, можно решить поставленную задачу.

Единственное требование к клиенту заключается в наличии навигатора, поддерживающего Java. В качестве платформ могут быть использованы ПК с Windows 3.x, 95 и NT, компьютеры Macintosh и рабочие станции Sun Microsystems.

Клиентская часть системы Forum полностью написана на Java, серверная часть — на C. Стремясь как можно раньше создать свой продукт, в AIS начали работу, не дожидаясь появления таких инструментальных систем, как Java Workshop. Тем не менее, команде из пяти программистов удалось создать первую версию Forum за два месяца.

Система Forum работает сейчас на 10 серверах (SPARCstation 20 и выше), клиентами чаще всего служат ПК под Windows 95.

По оценке президента AIS Джона Шнейдера, экономия на разработке оказалась существенной, а скорость разработки и надежность продукта превзошли ожидания. "Я благодарен Java за возможность создавать приложения, распространяемые по сети, я не вижу ничего, сравнимого по возможностям" — заявил Шнейдер.

Заключение

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