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

Составляя длинный список проблем в области защиты, возникающих при использовании приложений на базе мобильного кода, любой здравомыслящий администратор ИТ неизбежно задается вопросом, а зачем вообще все это нужно? Для многих приложений мобильный код действительно не нужен. Если кому-то требуется реализовать распределенную разработку, он может установить статичных клиентов и организовать их взаимодействие с сервером. Если кому-то требуется тонкий клиент, он может просто передавать с сервера простой текст HTML в клиентский браузер, где пользователь вводит данные в поля форм; при этом все, что происходит, — это простейшее перерисовывание экрана для представления приложения.

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

КТО РАЗДЕЛЕН, ТОТ ИЩЕТ

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

При всей любопытности деталей процесса сканирования самих по себе (подробности см. на http://setiathome.ssl.berkeley.edu/about_seti/about_seti_at_home_1.html) для нас гораздо большее значение имеют гигантский объем перемалываемых данных и статичный характер процесса обработки. Объем машинных расчетов, необходимых для обработки относительно малой порции данных, передаваемой на ПК одного добровольца, весьма впечатляет: около 175 млрд операций, или приблизительно 25 часов непрерывных расчетов на типичном ПК с процессором Pentium.

На данный момент свой вклад внесли свыше 1,2 млн пользователей, в сумме он составляет 90 000 лет времени ЦПУ. Как бы впечатляюще эти цифры ни выглядели, главное — что все эти ЦПУ делают одно и то же: каждый ПК следует тем же самым процедурам на протяжении трех лет существования проекта, так что все блоки данных обрабатываются одинаково. Добровольцы просто один раз устанавливают программное обеспечение для обработки данных, и, собственно, все.

Другими словами, здесь мы не имеем дела с мобильным кодом. Решив помочь в обработке данных, пользователь загружает программное обеспечение и устанавливает его на свою систему точно так же, как любое другое распаковываемое приложение. Если бы ПК требовалось выполнять большое число различных видов расчетов над одним из типичных для проекта «рабочих блоков» объемом 300 Кбайт, то картина была бы иной. В этом случае хранить каждый из 100 различных процессов не имело бы смысла. Вместо этого компьютер мог бы загружать необходимый для обработки компонент при выделении ему специфического рабочего блока.

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

ПИТТСБУРГСКИЙ СЛУЧАЙ

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

Идея, легшая в основу Street Smarts, проста: отправляя муниципального служащего на городской объект, его желательно предупредить о возможных опасностях. Для этого, вообще говоря, необходимо просмотреть информацию множества городских служб, например записи звонков по 911, полицейские протоколы и жалобы в коммунальную службу.

К сожалению, такая информация хранилась на разных серверах и в разных базах данных. Предварительный анализ в начале проекта выявил базу данных Oracle на сервере Sun, ее же, но более старой версии, на сервере AT&T, анклав серверов NetWare, где выполнялась Btrieve, и систему Bull, лучшие дни которой уже позади.

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

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

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

Следующий шаг состоял в выводе системы Street Smarts на улицы и установке карманных устройств на базе Windows CE в патрульных автомобилях и подключении их к системе с помощью беспроводных сетевых технологий. Эти намерения — т. е. то, что система будет выполняться на тонких клиентах со средствами соединения с низкой пропускной способностью, — заставили Cerebellum отдать предпочтение системе, где браузеру бы не передавались никакие компоненты кода. «Мы стремились ограничить функции браузера представлением текстов HTML, — говорит Ольсон. — Немалую роль сыграл также вопрос совместимости — мы не хотели создавать себе лишние трудности из-за различий в механизмах Java в браузерах Microsoft и Netscape, и мы не хотели проблем при использовании тонких клиентов, которыми Java не поддерживается». Как указывает Ольсон, современное поколение браузеров CE не имеет механизмов Java или JavaScript.

ТАК КТО ЖЕ МОБИЛЬНЫЙ?

Наверно, у кого-то из читающих эти строки уже кончается терпение: так когда же автор приведет пример приложения на базе мобильного кода, да и есть ли такие вообще? Хорошим примером такого приложения может служить McAfee Clinic. Вы можете опробовать его сами, так как оно доступно для всех желающих через Web. Clinic представляет собой платную службу для индивидуальных потребителей с абонентской платой 49 долларов в год. (На момент выхода статьи компания McAfee предоставляла возможность бесплатного ознакомления со службой.) Помимо прочего, Clinic сканирует систему на предмет наличия вирусов непосредственно из браузера.

Рисунок 1. The McAfee Clinic в действии. Clinic сканирует выбранные разделы жесткого диска с использованием компонентов ActiveX и файлов данных с сигнатурами вирусов, причем и те и другие загружаются на лету.

Если McAfee Clinic используется в целях сканирования системы на предмет наличия вирусов, то вы наверняка обратили внимание, что вся процедура выглядит иначе, чем в случае, когда требуется заполнить форму HTML и нажать кнопку SUBMIT. Вместо этого используемые элементы управления читают содержимое локального жесткого диска и среды и активно реагируют на них, как показано на Рисунке 1. Это оказывается возможно потому, что McAfee загружает порцию кода как часть соответствующей страницы Web на сервере Clinic.

«По сути, во всех своих приложениях Clinic использует ActiveX, и только небольшая часть кода располагается на жестком диске пользователя Clinic, — говорит Бо Робертс, менеджер по продуктам McAfee Clinic. — Механизм сканирования и файл DAT с определениями всех вирусов находятся на жестком диске. Таким образом, при выполнении приложения все сканирующие компоненты выполняются локально. Никакой информации о жестком диске или файлах пользователя на наш сервер не передается. При выполнении приложения мы каждый раз проверяем номер версии файла DAT на случай необходимости внесения усовершенствований в код — все это загружается автоматически».

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

Взяв на вооружение ActiveX, компания, по словам Робертса, столкнулась с вопросами совместимости клиентов, из-за чего вся архитектура мобильного кода оказалась под угрозой. Браузеры Netscape не поддерживают ActiveX, по крайней мере, без загрузки и установки специализированного подключаемого модуля. «Пользователи Netscape выражают недовольство тем, что им отводится роль второй скрипки, — рассказывает Робертс. — Но нам пришлось выбирать: ActiveX или Java. Из-за ограничений Java в части доступа к жесткому диску и файловой системе мы остановили свой выбор на ActiveX, так как эта технология позволяла получить доступ к низкоуровневым функциям локальной системы». Если бы Java и ActiveX имели равные возможности с точки зрения доступа к локальному жесткому диску, то, по словам Робертса, McAfee, вероятно, отдала бы предпочтение Java в силу ее относительной независимости от используемой платформы.

ПЕРЕМЕЩАЮЩИЕСЯ АППЛЕТЫ

Если вы действительно испытываете интерес к мобильному коду, то вам не мешает познакомиться с так называемыми «мобильными агентами» — прикладными системами, существовавшими до сих пор главным образом в рамках исследовательских проектов в университетах. Возможно, наиболее известным из них является проект Mole, с которым любой желающий может познакомиться на http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole.html. Понять, как эти проекты соотносятся с реальным миром, можно на примере Jumping Beans — коммерческого продукта с использованием мобильных агентов. Эту технологию разработала компания Ad Astra Engineering.

Jumping Beans позволяют создавать приложения, которые могут выполняться на одной машине, упаковывать свое текущее состояние для передачи, перебираться на другую машину и продолжать выполнение на этой новой машине, даже если прежде они никогда на ней не устанавливались. Технология опирается на концепцию «грузоперевозок», как описывается в книге «Клиент-серверное программирование с помощью Java и CORBA», написанной Робертом Орфали и Дэном Харки.

Идея состоит в том, что программы запускаются локально, а затем рассылаются по сети для выполнения своей работы на машинах, где они выполняются локально, используют доступные драйверы устройств и таким образом получают более быстрый и простой доступ к имеющимся на этих машинах ресурсам. По мнению Криса Райгарда, главного архитектора в Ad Astra, это упрощает разработку, поскольку разработчикам программ приходится иметь дело только с локальными системами. Кроме того, Райгард утверждает: «Само развертывание программы изменяется и упрощается. Все, что вам необходимо сделать вначале, — установить демон Jumping Beans на свою машину. Затем распределенные приложения можно будет запускать с любой машины, не предпринимая никаких усилий по их распространению, так как это является неотъемлемым свойством приложения».

По словам Райгарда, инфраструктура наподобие Jumping Beans открывает новые возможности по управлению системами и устройствами именно благодаря разрешению локального доступа мобильного приложения к локальным ресурсам. «При использовании современных средств управления сетью агента SNMP приходится загружать на каждое управляемое устройство, и к тому же с ним необходимо взаимодействовать по сети, — указывает Райгард. — Во многих случаях пользователям приходится довольствоваться тем, что Cisco Systems «зашила» в устройство на фабрике. Опираясь на мобильность, мы работаем с провайдерами программного обеспечения управления сетями над решениями, при которых сетевым устройствам достаточно было бы иметь только загруженных клиентов Jumping Beans — в особенности это касается тех устройств, у которых пользовательский интерфейс отсутствует, как у сетевых принтеров и маршрутизаторов.

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

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

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

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

О ЧЕМ ЕЩЕ БЕСПОКОИТЬСЯ?

Радикальное различие между «старыми добрыми» апплетами или компонентами ActiveX и мобильными агентами состоит в том, что компонент Jumping Beans или аналогичный ему в действительности выполняется на нескольких машинах, а не на одной. К сожалению, это порождает новые проблемы в области защиты: заботиться приходится не только о том, что вредоносный компонент может нанести ущерб клиентской (целевой) системе, но и о том, что сама клиентская система может атаковать мобильный компонент, в результате чего его целостность может пострадать, и он прибудет на следующий по порядку узел уже испорченным.

Рисунок 2. Архитектура Jumping Beans. Каждый прыжок приложения с одного хоста на другой осуществляется через сервер домена Jumping Beans, реализующий меры защиты и сохраняющий промежуточные состояния, благодаря чему любой прерванный процесс может быть восстановлен. На этой диаграмме рабочая станция 1 создает приложение и отправляет его по маршруту «рабочая станция 2 — рабочая станция 3 — рабочая станция 4», после чего приложение возвращается на станцию 1.

В архитектуре Jumping Beans центральное место занимает сервер, как показано на Рисунке 2. Конечно, для обеспечения мобильности кода сервер не нужен, но Ad Astra использует его вовсе не для этого, а для повышения эффективности управления и, в частности, для укрепления защиты.

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

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

Как считает Райгард, если система с самого начала не разрабатывалась с учетом обеспечения собственной защиты, то она не сможет предоставить адекватную архитектуру защиты для поддержки мобильного кода. Как и Java, «Jumping Beans создавались с защитой в уме, — говорит он. — В ActiveX же меры защиты изначально не предусматривались, и модель защиты была добавлена потом. В результате дыры в защите оказываются, по сути, неизбежными».

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

СКОРО НА ПОСАДКУ?

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

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

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

Да, конечно, все эти задачи можно решить, не прибегая к мобильности. «Нет ничего такого, чего нельзя было бы сделать традиционными средствами, без помощи мобильных средств, — признает Райгард. — Однако, с точки зрения разработчика, процесс разработки оказывается намного проще, когда ему приходится иметь дело только с одним мобильным приложением. В противном случае ему придется создавать клиентский компонент, сервер, внутренний интерфейс с сервером и т. д.».

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

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

Роберт Ричардсон — мобильный агент, поэтому он иногда чувствует себя недостаточно защищенным. С ним можно связаться через его сервер Web с адресом: http://www.SmallOfficeTECH.com.

Ресурсы Internet

Независимый обзор и анализ платформы Java 2 (которую Sun Microsystems позиционирует как специально предназначенную для реализации корпоративных приложений на базе мобильного кода) можно получить от Gartner Group на http://www.gartner.com/webletter/sunus/default.html.

Последней новинкой в технологии COM компании Microsoft является ее объединение с расширяемым языком разметки (Extensible Markup Language, XML) под общим названием Windows DNA 2000. Прочитать об этом можно на http://www.microsoft.com/dna/.

Загрузить Jumping Beans для ознакомления можно с http://www.jumpingbeans.com.

О проектах на базе Web с использованием кода мобильных агентов можно прочесть на http://www.physik.uni-bielefeld.de/experi/d3/persons/struve/kaariboga/resources.