Java и ActiveX: что лучше для интрасети?

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

Элементы архитектуры Java и ActiveX

ПОЧЕМУ НЕ ОБЕ СРАЗУ?

Когда компания HealthData Resources (HDR), специализирующаяся на медицинских системах, начала выбирать платформу разработки приложений для интрасети, она нашла по меньшей мере одну убедительную причину, чтобы отдать предпочтение технологии Java от Sun Microsystems перед ActiveX от Microsoft. Программисты HDR уже работали на C и C++, поэтому некоторые специалисты отдела информационных технологий (ИТ) решили, что переход к основанному на C++ языку Java окажется несложным. Но хотя это соображение было существенным, оно не смогло перевесить аргументы, выдвинутые в пользу ActiveX.

Да, язык C++ полностью устраивает программистов, однако для работающих в медицинских центрах и больницах специалистов по ИТ, которые создают приложения для интрасетей, предназначенных для доступа к системам компании HDR, переход на него стал бы гигантским шагом. По словам Эда Ризинджера, менеджера по продуктам компании HDR, большинство специалистов по ИТ решило, что значительно проще работать с управляющими элементами ActiveX (ActiveX Controls) - эквивалентами Java-аплетов, - поскольку их можно писать на разных языках, в том числе на простом Visual Basic.

У HDR также возникла проблема с моделью безопасности Java, называемой "песочницей" (sandbox). В соответствии с этой моделью загружаемым аплетам запрещено обращаться к файлам и периферийным устройствам системы, в которой они работают. Проблема связана с тем, что для сбора различной информации, например о страховке пациентов, и отслеживания статистики по заболеваниям компания использует смарт-карты. "С помощью Java вы не сумеете получить доступ к устройствам чтения и записи смарт-карт", - объясняет Ризинджер. Есть и еще одно соображение, которое Ризинджер не смог проигнорировать, - доминирующее положение Micro-soft на рынке. "Microsoft - крупнейший производитель программного обеспечения в мире. Я не хочу делать ставку против лидера", - говорит он. В самом деле, HDR использует в качестве стандартной платформы Windows 95, поэтому кросс-платформенные возможности, т. е. главное преимущество Java, не являются для нее необходимыми.

HDR не одинока в своей попытке противопоставить друг другу две технологии. Все больше компаний отходят от простых HTML-страниц и сценариев CGI (Common Gateway Interface), пытаясь создавать интерактивные приложения для интрасетей. Менеджерам по ИТ приходится старательно искать компромиссы, выбирая архитектуру разработки Web-приложений от Sun или Microsoft. И хотя технологии Java и ActiveX часто представляют непримиримыми конкурентами, в действительности они решают разные части головоломки под названием "интрасеть".

В чем различие?

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

ActiveX является ориентированной на интрасети версией протокола OLE компании Microsoft, определяющего, как приложения могут взаимодействовать друг с другом и обмениваться информацией в среде Windows и Windows NT. Расширения ActiveX дают возможность OLE-совместимым компонентам приложений - управляющим элементам ActiveX - взаимодействовать в клиент-серверной среде интрасети.

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

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

Как говорит Дж. Лоуренс Подмолик, директор по технологиям компании Strategic Technology Resources, специализирующейся на интеграции основанных на интрасетях систем, свои перспективы имеют и Java, и ActiveX - все зависит от конкретных потребностей заказчиков. Технология ActiveX имеет такие элементы, как OLE и Visual Basic, и является более зрелой, чем Java, поэтому для нее существует больше инструментальных средств. Однако Sun и ее партнеры быстро наполняют рынок средствами разработки на Java. Подмолик утверждает, что эти средства плюс кросс-платформенные возможности Java делают эту технологию бесценной для компаний, использующих различные клиентские платформы.

Java: хорошо, но не отлично

Однако даже те специалисты по ИТ, для которых выбор в пользу технологии Java является очевидным, отмечают ее недостатки. Например, перестраховочная фирма Munich Reinsurance Company of Canada ознакомившись с ActiveX, отказалась от использования этой технологии. "ActiveX не дает ничего такого, что нельзя было бы получить с помощью Java, и не обеспечивает переносимости клиентского ПО", - утверждает Джо Голобик, помощник вице-президента по ИТ расположенного в Торонто подразделения немецкой компании Munich Reinsurance.

Munich Reinsurance имеет основанное на интрасети хранилище данных о клиентах, к которому имеют доступ с помощью загружаемых в браузеры аплетов Java 4,5 тыс. пользователей Windows и Macintosh со всего мира. По словам Голобика, хотя специалисты по ИТ уверены в правильности выбора платформы для приложений, использование Java вызвало ряд проблем у разработчиков, пытающихся запрограммировать определенные функции, в частности управления графическими элементами на Web-страницах.

Компании удалось решить проблемы программирования благодаря стороннему продукту - Apptivity от Progress Software. Обеспечиваемая им удобная графическая среда разработки позволяет легко справляться с наиболее трудоемкими задачами программирования на Java, такими как прорисовка экранов и организация связи между клиентским ПО и сервером базы данных. Например, Голобик утверждает, что создание первого приложения с помощью Apptivity отняло у программистов компании всего несколько месяцев; если бы они использовали только Java, на это потребовалось бы около двух лет.

Атрибуты ActiveX

Выбор в пользу ActiveX обычно делают компании, вложившие большие деньги в системы клиент-сервер и инструментальные средства компании Microsoft. Когда нью-йоркская компания Merrill Lynch & Co. начала выбирать стандартную платформу разработки приложений для интрасети, она уже в течение двух лет активно пользовалась настольными операционными системами Windows, технологиями OLE и DCOM (Distributed Component Object Model). По словам Пола Каневски, директора по разработке ПО, это означает, что компания имела множество готовых управляющих элементов и программных модулей, а также опыт разработки приложений для настольных систем Microsoft.

В Merrill Lynch технология ActiveX позволила вполне гладко перевести настольные системы от OLE к интрасети. Сейчас компания разрабатывает систему Trusted Global Advisor, которая обеспечит 25 тыс. сотрудникам Merrill Lynch доступ к информации о клиентах с помощью примерно 25 приложений. Как говорит Каневски, некоторые приложения системы Trusted Global Advisor основаны на технологии интрасети, другие - на архитектуре клиент-сервер, а третьи являются внутренними разработками компании и функционируют только на настольных ПК. Посредством OLE и ActiveX все эти приложения интегрированы с единым браузером и настольной средой Windows NT.

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

По словам Ризинджера, HDR долгое время откладывала перенос больших частей приложений с DOS на Windows, чтобы избежать необходимости "обновлять тысячи настольных систем при каждом выпуске Microsoft очередного обновления Windows". Централизованное автоматическое обновление клиентского ПО, которое стало возможным благодаря ActiveX, позволило сотрудникам отдела ИТ наконец-то перенести оставшиеся части приложений на Windows.

Понемногу того и другого?

Иногда имеет смысл использовать и Java, и ActiveX - особенно компаниям из списка Fortune 500, имеющим разнородные клиентские платформы, компьютерные конфигурации и проекты, связанные с разработкой приложений.

Именно так обстоят дела в компании Shell Services (дочерняя фирма Shell Oil), которая предоставляет услуги по ИТ различным подразделениям Shell. В компании пришли к выводу, что Java наилучшим образом подходит для групп пользователей, применяющих Unix и браузеры компании Netscape Communications. Однако если клиент использует Microsoft Internet Explorer и хочет иметь доступ из браузера к Excel или другим приложениям Microsoft Office, ему больше подойдет ActiveX. "Используя управляющие элементы ActiveX, можно осуществлять доступ к уже имеющимся приложениям, вместо того, чтобы писать их заново, - что необходимо в случае применения Java", - говорит Иоанис Караламбус, менеджер по эксплуатации из Shell Services. Он считает это большим плюсом в пользу ActiveX.

И это справедливо даже для компании Merrill Lynch, хотя она использует, главным образом, NT. "При работе с базами данных SQL использование ActiveX не является проблемой. Однако ActiveX не очень хорошо подходит для связи с некоторыми источниками данных, с которыми нам необходимо взаимодействовать, и нестандартными внутрикорпоративными приложениями для работы с базами данных. Такой доступ нам обеспечивают аплеты Java", - сообщает Эдвард Симмонс, вице-президент Merrill Lynch.

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

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

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

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

Однако схема безопасности ActiveX может оказаться недейственной, когда пользователи загружают управляющие элементы из World Wide Web, особенно из неизвестных или сомнительных источников, считает Ризинджер. Это - одна из причин, по которым HDR снабжает сертифицикатом средства разработки смарт-карт, которые она распространяет через Internet, добавляет он.

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

Что же касается производительности, то поскольку Java является интерпретируемым языком, аплеты Java выполняются на виртуальной машине клиентской системы с меньшей скоростью, чем скомпилированные управляющие элементы ActiveX. С другой стороны, аплеты Java очень компактны, поэтому быстро загружаются, а для загрузки управляющих элементов ActiveX "нужна вечность", указывает Ризинджер. Однако, возражает Симмонс из Merrill Lynch, загруженный управляющий элемент остается в клиентской системе, тогда как все элементы аплета Java необходимо каждый раз загружать заново. Это может сказаться на производительности, если пользователю нужно загрузить все виды "приспособлений" (widgets) для Java.

Лишь дайте время

Несмотря на все недостатки текущих реализаций технологий Java и ActiveX, менеджеры отделов ИТ рассчитывают на новшества главных производителей и их сторонних партнеров. К ним относятся, например, следующие.

Как утверждает Голобик, расширение модели "песочницы" является одним из основных пожеланий компании Munich Reinsurance. "Мы находим выходы из положения, но вывод данных на печать, например, выполняется в четыре этапа". Однако в целом Голобик удовлетворен прогрессом Java в направлении зрелой архитектуры для интрасетей: "Есть множество вещей, которые мы бы хотели увидеть в Java, и я надеюсь, что Sun сможет обеспечить их достаточно быстро".

Элементы архитектуры Java и ActiveX

ПОЧЕМУ НЕ ОБЕ СРАЗУ?

Когда речь заходит о технологиях ActiveX и Java, менеджеры интрасетей вовсе не обязаны делать выбор по принципу "или-или". Чисто технически интеграция этих двух сред разработки приложений для интрасетей возможна, однако смельчакам, которые возьмутся за реализацию подобного проекта, придется полностью отойти от другой работы. Например, аплеты Java могут выполняться в среде ActiveX, но тогда для них нужно создать специальные оболочки или мосты. Как утверждает Дж. Лоуренс Подмолик, директор по технологиям консалтинговой компании Strategic Technology Resources, это отнюдь не тривиальная задача.

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

Проблема грозит еще больше усложниться, когда компании начнут создавать распределенные компонентные архитектуры, использующие модели Distributed Component Object Model (DCOM) от Microsoft, Remote Method Invocation (RMI) от SunSoft и Common Object Request Broker Architecture (CORBA) от Object Management Group.

Позиция Microsoft предельно ясна: используйте DCOM. Клиентские и серверные компоненты на Java могут взаимодействовать друг с другом через DCOM, и любой Java-объект на стороне клиента или сервера может взаимодействовать с любым клиентским или серверным объектом DCOM, утверждает представитель Microsoft. По его же словам, Microsoft не планирует поддерживать RMI. Кроме того, компания не сообщает о своих планах относительно поддержки Internet Inter-ORB Protocol (IIOP) - спецификации CORBA, определяющей способы объединения компонентов приложений через сеть.

Позиция Sun несколько сложнее. Компания рекомендует использовать только RMI для взаимодействия аплетов Java, но ей пришлось ответить на давление со стороны пользователей и анонсировать планы по реализации поддержки в RMI протокола IIOP. При этом, правда, конкретные сроки не указываются. По словам представителей Sun, такая поддержка позволит аплетам Java вызывать объекты CORBA по протоколу IIOP. Но необходимость использовать также RMI может показаться некоторым разработчикам приложений для интрасетей слишком обременительным.