Универсальный сервер приложений "Тарантелла"

Выпустив в 1997 г. в составе ОС UnixWare сервер приложений "Тарантелла" [1], компания SCO продемонстрировала совершенно новый подход к проблеме интеграции разнородных вычислительных ресурсов, отличный как от традиционных средств Unix-платформ, так и от нововведений, родившихся в среде Windows.

"Тарантелла" позиционируется как универсальный сервер приложений для сетевых вычислений, который способен обеспечить доступ к любым типам приложений независимо от того, где они выполняются - на мэйнфреймах, платформах Unix или Windows, - с любых клиентов, включая сетевые компьютеры и ПК (рис. 1). Не требуется ни модификации приложений, ни установки на клиентской стороне дополнительных программных средств. Единственное, что нужно клиенту - Web браузер с Java-машиной. Выглядит привлекательно, не правда ли?

С "Тарантеллой" приложения не инсталлируются на клиентских компьютерах - они работают на своих серверах и взаимодействуют с пользователем через загружаемые Java-апплеты. Доставка новых приложений и версий происходит мгновенно: просто администратор сервера "Тарантеллы" делает их доступными пользователям.

Все пользователи взаимодействуют с "Тарантеллой" через одинаковый интерфейс - Webtop (по аналогии с Desktop), управление которым как рабочей средой осуществляется централизованно. Данная среда всегда доступна независимо от того, где находится пользователь и какое устройство он применяет.

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

1. Какие проблемы решает "Тарантелла"?

До 80-х г. собственные сети имели, пожалуй, только крупные корпорации, используя их как средство связи с мэйнфреймами. В качестве устройств доступа (клиентов, в современной терминологии) выступали терминалы со специализированными аппаратными средствами и оригинальными протоколами. С ростом популярности UNIX-серверов пришла стандартизация сетевых протоколов, в частности, TCP/IP. В тот же период произошел сдвиг вычислительной парадигмы в направлении модели клиент-сервер. Основной причиной послужило широкое распространение ПК - клиенты стали более интеллектуальными и эффективными. Клиентский desktop MS Windows быстро наращивал функциональность и оказался способен взять на себя часть нагрузки, ранее лежавшей на сервере.

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

(1x1)

К этому времени на первое место среди компьютерных технологий вышли Internet и WWW - доступность сетей и ежегодное удвоение скоростей передачи информации cтали нормой. Сегодня мы вступаем в эру Сетевых Вычислений (Network Computing), и от того, как будут использоваться новые возможности, зависит многое. Однако развитие современных подходов к организации вычислений невозможно без учета проблемы преемственности со старыми технологиями. К сожалению, на предыдущих этапах процесс развития был достаточно хаотичным, и в индустрии программных средств создавались разнообразные, плохо согласующиеся друг с другом смеси технологий и архитектур. Теперь влиятельные лица компьютерного сообщества пытаются убедить всех, что нужно выбросить старье на свалку и создать гомогенный мир из одного типа серверов и одного типа клиентов. Энтузиазм радикалов понятен: такой путь - это доходы для них, расходы для нас. Хочется верить, что их мечте не дано осуществиться, а развитие будет идти по линии постоянного усовершенствования старых методов и постепенной их замены более прогрессивными. Сервер "Тарантелла" создает аппарат для этого - старое ПО может продолжать работать на прежних архитектурах, и в то же время обеспечивается платформа для реализации современных систем по новым технологиям.

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

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

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

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

"Тарантелла" решает эти проблемы следующим образом. Вся информация о пользователях и приложениях состредоточена на центральном сервере. В тот момент, когда пользователь подсоединяется к нему, по этим описаниям формируется его индивидуальная рабочая среда - Webtop, которая доставляется на клиентскую машину пользователя по Адаптивному Internet Протоколу. Через Webtop он может обратиться к любому из доступных для него приложений или документов, а Адаптивный Протокол учитывает наличие различных типов клиентов и разнообразие сетевых связей (с низкой или высокой пропускной способностью и латентностью).

2. Интерфейс пользователя в модели сетевых вычислений

Интерфейс пользователя с приложением развивался от символьной формы к оконной. Оценивая эту трансформацию с современных позиций, следует признать, что она радикально изменила устоявшийся в свое время взгляд на то, каким вообще должно быть приложение, и в результате компьютер начал играть в обществе совершенно иную роль, став общедоступным. Совсем по- другому обстоит дело с Сетью, которая вроде бы не должна оказать никакого влияния на интерфейс пользователя. Какая собственно разница, каково расстояние от компьютера до клиента - метр или несколько тысяч километров? Так и казалось с самого начала, и в 80-х г. разработчики первой масштабной оконной системы X Window делали акцент на прозрачность сетевого доступа. Сейчас ясно, что этот подход, сыгравший важную роль, нуждается в радикальном пересмотре именно для сетевых вычислений. На это повлияли два обстоятельства.

Во-первых, X протокол, по которому происходит передача данных из приложения (клиента) к системе, визуализирующей интерфейс пользователя (X сервер), оказался недостаточно быстрым. Это обусловлено не дефектами его конструкции, а тем, что API X Window имеет низкий уровень - он располагается сразу над драйверами ввода/вывода, - и X Window приложение работает с простейшими графическими объектами, строя из них более сложные. По-видимому, мало кому придет в голову программировать интерфейс непосредственно средствами X Window. Поэтому большую часть API Microsoft Windows, сделанного по аналогии с X Window, составляет обширный набор элементов интерфейса, и этот инструментарий действительно эффективен. Естественно, аналогичные средства есть и для X Window: Motif или OpenLook. Но это надстройка, а сама связь клиента и X сервера происходит по X протоколу, передающему примитивные объекты. Такая организация некомпактна, она приводит к необходимости передавать большие объемы данных, интерфейс становится медленным, что и наблюдается даже в локальном варианте сетевого доступа.

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

Условие продуктивности такой программы для гетерогенной среды - стандартизация нового протокола, однако история распорядилась иначе: родилась Java- технология или, скажем так, возможность передавать по сети программы на урезанном C++.

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

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

Основа Web, HTML, сам по себе для этого не годится - это язык описания данных. Есть другой путь: Web-браузеры имеют API, позволяющее развивать их функциональность путем стандартизованного подключения вставных модулей (plug-in). Обычно это модули для работы с такими типами документов, которые не поддерживаются основным браузером. Этот способ хорош прежде всего тем, что он очень прост; подключить готовый модуль может и сам пользователь, но как общий механизм обеспечения интерфейса он не универсален. Например, вставные модули должны быть зависимыми не только от платформы, но и от браузера. Для двух платформ (Windows и UNIX) и двух типов браузеров (Netscape и Microsoft), необходимы четыре реализации подключения.

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

Сейчас, когда необходимо выбрать, на какую технологию использования Сети будет сделана ставка, вопрос стоит очень остро. По сути дела для многих приложений существуют две реализации: одна для локального использования и вторая для удаленного сетевого. Пример тому - объявление о версии офисного пакета Lotus на апплетах Java [2]. Разработанные ранее интерфейсы с базами данных переписываются на CGI. Будет смешно, если ситуация, когда нужно делать два варианта интерфейса с пользователем продлится достаточно долго.

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

Первый и, пожалуй, главный вопрос уже затрагивался: проблема перехода на единые средства реализации интерфейса пользователя тесно переплетена с проблемой использования накопленного ПО. Разработчики SCO исходили из того, что его никто не будет просто так выбрасывать или сразу переписывать - слишком дорого это стоит. Неспроста большое количество поставщиков предлагает символьные или графические пакеты, которые работают на традиционных desktop клиента, таких как Windows, UNIX, и эмулируют нестандартные или "неродные" протоколы. Этот же способ, эмуляция интерфейса приложений, предлагается и в "Тарантелле", но Java-эмулятор обладает большими достоинствами - он может работать почти с любым клиентом.

3. Распределение приложений

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

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

4. Доступ к приложениям

Известно несколько способов доставки приложений пользователям: локальная установка, технология выталкивания (push), доступ по запросу.

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

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

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

5. Обслуживание пользователей

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

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

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

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

6. Оптимальная производительность сети

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

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

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

7. Как работает "Тарантелла"?

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

7.1. Интеграция сетевых ресурсов

Весьма досадно, что уже для ключевого момента доступа к ресурсам сети, их именования, используется целый ряд стандартов и методов. Например, для адресации компьютеров в Internet применяются такие разные соглашения, как DNS (Domain Name Service) или WINS (Windows Internet Naming Service). Правила присваивания имен файлам привязаны к операционным системам, так, например, Microsoft применяет UNC (Universal Naming Convention) - соглашения, отличные от принятых в UNIX. Ресурсы платформ различаются и по существу - для доступа к ним необходимы разные методы и точки входа. Решая эту проблему, "Тарантелла" обеспечивает интеграцию широкого спектра стандартов именования, создавая объединенное пространство имен и предоставляя единую точку входа для доступа к любым ресурсам сети. Реализация этого подхода в "Тарантелле" построена по схеме, основанной на X/Open Federated Naming (XFN).

Обычно вся информация о сетевых ресурсах поддерживается серверами каталогов, которые тоже различны, к примеру: NDS (Novell), Directory Server (Netscape), Active Directory (Microsoft). "Тарантелла" не пытается полностью заменить или дублировать эти службы - в ее состав входит тонкий слой, основанный на протоколе LDAP (Lightweight Directory Access Protocol), позволяющий с ними взаимодействовать. Сегодня LDAP фактически промышленный стандарт интерфейса со службами каталогов.

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

7.2. Компоненты и функции

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

• сервер;
• средства протокола и отображения;
• управление рабочей средой пользователя;
• Адаптивный Internet Протокол;
• приостановка/продолжение сеансов;
• инструментальные средства администрирования и управления.

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

Машина управления состоянием выполняет инициализацию "Тарантеллы" (первый процесс, который начинает работать при ее запуске) и управляет всеми другими серверными средствами. Эта машина действует как центральная точка для всех остальных процессов. В нее поступают все запросы, которые она переадресует подходящим подсистемам, вызывая выполнение требуемых действий.

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

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

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

Машина протокола - именно то средство, которое делает "Тарантеллу" универсальным сервером приложений. Происходит это следующим образом. Машина протокола функционирует на сервере "Тарантеллы" и перехватывает все данные, направляемые клиенту из приложения, работающего на каком-либо другом сетевом сервере. С ними машина протокола поступает как переводчик: понимая стандартные протоколы, используемые современными приложениями, она транслирует их в Адаптивный Internet Протокол, на который рассчитаны машины отображения. Благодаря этому методу, существующие приложения продолжают работать на своих серверах, не нуждаясь в каких-либо аппаратных или программных изменениях. Поскольку машины протокола работают на сервере, они оптимизируются для конкретной операционной среды, что обеспечивает высокую производительность эмуляции. Отметим еще один важный момент. Очевидно, что при данном подходе очень велики возможности расширяемости "Тарантеллы": чтобы подключить еще один тип приложений с новым протоколом, достаточно реализовать очередную машину протокола - остальная среда "Тарантеллы" готова ее принять. Это позволяет надеяться, что "Тарантелла" будет быстро развиваться.

Машины отображения как таковой в "Тарантелле" нет - в этом качестве выступает набор Java-апплетов, который загружается в клиент по запросу. Этот набор универсален, так как не привязан к конкретным приложениям, и имеет небольшой, порядка 200 Кбайт, объем - этого как раз достаточно для рендеринга интерфейса приложений и обеспечения функций ввода. Даже в сетях с низкой пропускной способностью все апплеты можно загрузить очень быстро.

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

Не вполне подходит для доступа к приложениям и среда Web-браузеров. Браузеры используют навигационные модели, позволяющие двигаться вперед-назад между страницами. Это означает, что страница с работающим внутри нее приложением может стать невидимой. Стандартная реакция браузеров - временно поместить Java апплеты, находящиеся внутри невидимых страниц, в кэш, а через некоторое время эти апплеты вообще выталкиваются из него. Это, конечно, совсем не то, что требуется. "Тарантелла" обеспечивает непрерывную работу приложения и производит, когда нужно, автоматическое восстановление связи.

Управление рабочей средой пользователя. Все эти сложности совершенно не касаются пользователей сети, их деятельность предельно упрощается, как и полагается в концепции тонкого клиента. Рабочая среда, независимо от типа клиента, у всех одинакова - это окно Web-браузера, которое можно спокойно расширить на весь экран, там есть все, что нужно. Сам браузер необходим только для обращения к серверу "Тарантеллы", затем происходит заполнение рабочей среды - Webtop - пиктограммами, представляющими приложения и документы. Настройка Webtop производится индивидуально для каждого пользователя - он получает те ресурсы, которые соответствуют его статусу. Графические пиктограммы интеллектуальны: они реализованы через Java-апплеты, и когда пользователь нажимает на них, посылаются запросы на вызов приложения или документа для просмотра. Еще раз отметим, что весь этот механизм опирается на централизованные ресурсы, описания состояний клиентов и централизованное администрирование.

Адаптивный Internet Протокол. Все разнообразие возможных протоколов приложений сводится "Тарантеллой" к Адаптивному Internet Протоколу, согласно которому и ведется обмен с Java-клиентами различных типов. Протокол должен оптимизировать реактивность приложений путем учета характеристик участвующих в обмене сетевых связей. Для этого в ходе работы ведется мониторинг, а собранная информация используется эвристическим механизмом для адаптации к возможностям оборудования. Так, на основании измерения времени на передачу (латентности и пропускной способности) принимается решение о методе сжатия данных, выбирается ритм передачи для перегруженных сетей. Обладая большим "интеллектом" по сравнению с простым клиентском ПО, протокол с сервера управляет клиентским кэшированием и очередью графических операций. Еще одна эвристика - оптимизация управления окнами. Все данные, необходимые для полной перерисовки окна, накапливаются и затем передаются максимально быстро. Протокол выполняет также некоторые технические функции, связанные с Java: управление цветом и преобразование специальных графических функций.

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

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

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

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

Инструментальные средства администрирования и управления. С точки зрения интерфейса администратор "Тарантеллы" ничем не отличается от остальных пользователей. Он только наделен большими правами и ему доступен набор инструментальных средств управления. Эти средства графические, реализованы на Java и помещаются на его клиентский Webtop.

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

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

7.3. Механизм функционирования "Тарантеллы"

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

С помощью Web-браузера пользователь соединяется с Web-сервером, на котором работает "Тарантелла". Web-сервер возвращает страницу, содержащую апплет начальной загрузки. Этот апплет обращается к машине хранения данных через определенный порт и получает от нее апплет входа, который содержит сценарий аутентификации пользователя. Если имя и пароль набраны правильно, посылается следующий запрос в машину хранения данных, инициирующий поиск Webtop для данного пользователя. Динамически создается Web-страница: на нее в виде пиктограмм помещаются все объекты, приписанные к этому пользователю и находящиеся в хранилище данных. Затем страница загружается в браузер.

Когда пользователь нажимает на одну из интеллектуальных Java-пиктограмм, загружается Web-страница, связанная с указанным объектом. Если этот объект - приложение, происходит загрузка правильной машины визуализации, которая обращается к машине хранения данных для поиска приложения. Этот же запрос посылается и Менеджеру Сеанса, который проверяет, не запущено ли уже приложение и нет ли необходимости его возобновлять для данного пользователя.

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

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

7.4. Технические характеристики

В 1997 г. "Тарантелла" была реализована для серверов SCO UnixWare и Sparc Solaris, а в течение 1998 г. ожидаются версии для SCO OpenServer, HP-UX, IBM AIX, Siemens-Nixdorf SINIX и NT Server. Под "Тарантеллу" на сервере необходимо отвести 60 Мбайт дискового пространства плюс 8 Мбайт на каждого пользователя. К рекомендуемым клиентам "Тарантеллы" относятся сетевые компьютеры Wyse Winterm, JavaStation, а также ПК под Windows 3.11, 95 и NT. На клиенте требуется 8 Мбайт памяти для JVM, протокол TCP/IP и какой-либо из Web-браузеров.

Литература