Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

“Капризы” управляющих элементов ActiveX и Java-аплетов

Ричард Хоффман, Роберт Патт-Корнер

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

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

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

Java против ActiveX

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

Если вам требуется поддержка нескольких платформ сразу, то, безусловно, лучше всего выбрать Java. Элементы ActiveX тоже поддерживают некоторые не-Windows платформы, например такие, как Macintosh фирмы Apple Computers, однако Java обеспечивает куда более широкую поддержку клиентов и ОС. Кроме того, если необходим доступ извне к вашим ресурсам с помощью различных Web-браузеров (как, например, в сети типа extranet), то опять же Java имеет преимущества перед ActiveX и с точки зрения безопасности, и с точки зрения использования, поскольку без установки дополнительных модулей (plug-ins), например таких, как ScriptAccess компании NCompass Labs, элементы ActiveX не поддерживаются браузерами Netscape. Кроме того, в технологии Java благодаря использованию файлов Resource Bundles значительно легче локализовывать программы. Разумеется, в Java пока не полностью реализован принцип “пишется однажды — работает везде” (write once, run anywhere), тем не менее эта технология действительно лучше переносится на другие платформы, особенно по сравнению с ActiveX.

Элементы ActiveX больше всего подходят для контролируемых сред, например для приложений, работающих в интрасетях. Для создания цифровой подписи программного кода элементов ActiveX с целью обеспечения дальнейшей аутентификации служит фирменный метод Microsoft — Authenticode. Это, впрочем, не гарантирует их безвредность для работы хост-системы в отличие от Java-аплетов, работающих в так называемой “песочнице” (sandbox). Элемент ActiveX имеет доступ к файловой системе хоста и может свободно распоряжаться распределением оперативной памяти.

Если вы работаете только в средах, полностью базирующихся на ОС Windows, а вашим любимым браузером является Microsoft Internet Explorer, то технология ActiveX представляется нам вполне логичным выбором. Ее элементы реализуют модель одноразовой загрузки из сети, что сокращает время выполнения приложений при последующих обращениях к уже загруженному элементу (в версии 1.1 спецификации Java аплеты могут функционировать подобным образом, но не со всеми браузерами и только при условии наличия цифровых подписей в формате X.509). Если вы привыкли использовать в своих приложениях заказные управляющие элементы OCX (OLE Custom Control), написанные на языке Си++ или других языках программирования, то технология ActiveX позволит вам воспользоваться некоторыми из унаследованных программ.

Следует учесть, что свойства технологии могут в одном случае привести к возникновению проблем с безопасностью, а в другом — обернуться сущим благом. Например, простота доступа к файловой системе и прочим локальным ресурсам машины существенно облегчает разработку приложений для интрасетей. Другим положительным свойством является возможность воспользоваться самыми разными языками программирования, включая Си++, Delphi, PowerBuilder, Visual Basic и даже Java, для написания исходного кода элемента ActiveX.

Принятие решения

Прежде чем создавать элементы ActiveX, следует выбрать одну из двух библиотек: Microsoft Foundation Class (MFC) или ActiveX Template Library (ATL). При работе с MFC управляющие элементы получаются более громоздкими и требуют установки на локальной машине пользователя корректной версии динамически подсоединяемой библиотеки MFC DLL, иначе при работе с этими элементами могут возникнуть проблемы. Преимущество такого подхода заключается в том, что разработчики смогут уделять больше времени самому объекту программирования и меньше заботиться о разработке интерфейса.

Библиотека ATL труднее в изучении, в ней меньше ресурсов и примеров, чем в MFC. Однако она оптимизирована для работы с Интернет, что позволяет создавать менее тяжеловесные управляющие элементы, не требующие инсталляции MFC DLL на каждой хост-системе.

Одной из главных трудностей при разработке Java-приложений является принятие решения, для какой из версий виртуальной Java-машины (Java Virtual Machine — JVM) следует писать программу. Если вы хотите, чтобы приложение работало на самых разных клиентских системах, то “общим знаменателем” для них станет JVM версии 1.0.2. Однако у нее есть целый ряд серьезных недостатков, в том числе: примитивные элементы управления графического интерфейса пользователя (GUI controls), минимальное взаимодействие с базами данных, недостаточная степень детализации модели безопасности (например, операции файлового ввода-вывода запрещены полностью). Кроме того, с ее помощью нельзя выполнять некоторые самые простые задания, например вывод на печать.

JDK (Java Development Kit — набор средств разработки Java-приложений) версии 1.1.7 и недавно вышедшей версии 1.2 были значительно усовершенствованы и существенно обновлен набор их функций. В частности, в них появились: возможность использования аплетов с цифровой подписью (при определенных условиях это позволяет им хотя бы частично выйти за ограничивающие рамки “песочницы”); компонентная модель JavaBeans, файлы типа JAR, позволяющие “упаковывать” все необходимые классы в один загружаемый файл; мощная модель обработки событий и значительно усовершенствованный набор компонентов графического пользовательского интерфейса (Abstract Windowing Toolkit — AWT).

JDK версии 1.2 тоже предлагает очень мощную и многоуровневую модель безопасности, основанную на правилах разграничения доступа. В ней предусмотрены: графическая консоль пользователя для создания и поддержки базы данных правил; средство для управления заверенными цифровыми сертификатами X.509 версии 3 и ключами шифрования; компонент JARsigner, предназначенный для снабжения JAR-файлов цифровыми подписями и их подтверждения. Начиная с JDK версии 1.1, в Java реализован механизм JDBC (Java Database Connectivity), который благодаря поддержке совместимости JDBC-to-ODBC гарантирует доступ Java-приложений к самым разнообразным данным.

Встраиваемые модули

Серьезной проблемой для спецификации Java версии 1.1 является отсутствие полной поддержки ее как со стороны Netscape Navigator, так и Microsoft Internet Explorer. Наилучший способ справиться с этой проблемой — это использовать встраиваемый модуль (plug-in) для поддержки Java, который вместо поставляемой вместе с браузерами Netscape Navigator и IE версий 3.x и 4.x виртуальной Java-машины позволяет воспользоваться оперативными средствами управления Sun RTE (Run-Time Environment) версии 1.1 или 1.2. Этот модуль делает возможным не только полное использование средств Java версии 1.1 и 1.2, но и гарантирует их совместимость, что еще важнее. Модуль plug-in для Java 1.2 предоставляет доступ к интерфейсу API, используемому для получения электронной подписи и регистрации аплетов, а также смягчает накладываемые “песочницей” ограничения и кэширует JAR-файлы на локальном диске.

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

Развертывание аплетов и управляющих элементов

Контроль корректности версий управляющих элементов и аплетов по идее не представляет особой сложности. Любая стандартная программа контроля версий, например такая, как Microsoft Visual SourceSafe, должна уметь работать с файлами JAR, классами Java и управляющими элементами ActiveX. Для нужд же небольших команд разработчиков отлично подойдет JavaSafe — программа контроля программного кода Java от фирмы Sun. Однако непосредственное развертывание и использование аплетов и управляющих элементов — это совсем другая история; чтобы эти процессы протекали гладко, необходимо выполнить ряд действий.

Для Java-аплетов, подлинность происхождения которых проверяется с помощью цифровой подписи, по порядку должно быть выполнено следующее (подробнее об этом см. по адресу http://developer.java.sun.com/ developer/technicalArticles/Security/Signed/index.html).

1. Скомпилировать аплет.
2. Создать файл JAR.
3. Сгенерировать ключи.
4. Подписать файл JAR.
5. Произвести экспорт сертификата с открытым ключом.
6. Произвести импорт этого сертификата как доверенного.
7. Создать файл правил разграничения доступа (policy file).
8. Запустить аплет.

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

Существует эмпирическое правило: если элемент ActiveX осуществляет операции чтения или записи на диск, либо чтения или записи за пределами выделенной ему оперативной памяти (чего не может делать Java-аплет, помещенный в “песочницу”), значит, он небезопасен.

Многокомпонентные элементы ActiveX, которые работают с браузером IE 4.0 фирмы Microsoft, лучше всего размещать таким образом, чтобы они обеспечивали требования открытого стандарта описания ПО (Open Software Description — OSD), являющегося подмножеством словаря XML. Браузер IE 4.0 позволяет целиком встраивать OSD-файлы в файлы CAB, в которых содержатся также INF-файлы элементов ActiveX. Помимо этого стандарт OSD обеспечивает локализацию и поддержку различных платформ.

Следует убедиться и в том, что у всех ваших пользователей установлена одна и та же версия JVM или одна и та же версия библиотеки MFC (для тех элементов ActiveX, что требуют использования MFC, а не ATL). Работа с неверной версией JVM или MFC может стать причиной возникновения проблем несовместимости.

Для Java наилучшим способом обеспечения совместимости является использование соответствующего модуля Java plug-in. Короче говоря, вам надо унифицировать все версии браузеров — это единственный способ, который позволит программисту сосредоточиться на одной конкретной версии JVM и учесть все присущие ей характерные особенности. И наконец, не забудьте, что браузеры должны быть соответствующим образом сконфигурированы, т. е. в них должны загружаться и активизироваться Java-аплеты и управляющие элементы ActiveX, иначе все ваши хитроумные разработки будут недоступны для пользователей.

Наши открытия

При использовании управляющего элемента OCX в приложении “телефонная книга” у нас возникла следующая ситуация: этот элемент был успешно протестирован на нашей экспериментальной платформе, но при развертывании его в реальной рабочей среде у нас появились проблемы. На одной рабочей станции элемент работал безотказно, но на другой вдруг “засбоил” при выполнении операции socket read. Причина возникновения ошибки кроется в еле уловимом отличии версий MFC. В более новой версии, с которой элемент OCX работал корректно, ошибки, связанные с интерфейсом Socket, были уже исправлены. Сбой в работе возник из-за того, что реинсталляцию Microsoft Word на этой станции выполнил другой разработчик, причем он установил более старую версию библиотеки MFC.

С аналогичным развитием событий мы столкнулись и при развертывании Java-аплетов в проекте создания совместного планировщика, где под управлением JVM версии 1.0.2 должен был выполняться элемент управления деревом каталогов (tree control) сторонней разработки. Искомое же долговременное решение состояло в переходе на элементы, поддерживающие JVM версии 1.1 и расширение JFC SwingSet. К сожалению, многие из все еще работающих старых браузеров не поддерживают JVM версии 1.1. Кроме того, наша реальная среда состояла из браузеров разных фирм — Netscape и Microsoft, что также порождало целый ряд проблем во время исполнения аплетов из-за различий в реализации JVM этими браузерами. Нашим решением стала синхронизация JVM на всех браузерах при помощи встраиваемого модуля JavaSoft.





  
11 '1999
СОДЕРЖАНИЕ

колонка редактора

• А ты записался в просультанты?

локальные сети

• Пришло время Linux?

• Пластиковое оптическое волокно на пути к домашним кабельным проводкам

• Кабельные системы: проблема 2000 года

бизнес

• Роль дистрибуции в кабельном бизнесе

• Дилерская академия "Марвел"

• Сетевое управление: снова в школу

интернет и интрасети

• "Капризы" управляющих элементов и Java-аплеты

системы учрежденческой связи

• Тарификационные системы для УПАТС

корпоративные сети

• IOS это не только маршрутизация

• Коммутация на четвертом уровне. Что под этим подразумевают проиводители?

• Как построить оптимальную систему хранения данных

услуги сетей связи

• Об оценке качества речевой связи

• Российские операторы экзаменуют АТМ

• IP-телефонизация: быстрая замена или постепенная модернизация?

защита данных

• Trend InterScan: антивирусная безопасность на высшем уровне

• Cистемы обнаружения вторжений

• Как обеспечить конфиденциальность с помощью открытых ключей

новые продукты

• Объединяя сети; Новый DSL-концентратор MARS 9000 компании Tainet



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх