Java-технология как средство создания современных корпоративных систем

Олег Москаленко

Введение

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

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

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

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

История Java как средства создания корпоративных приложений

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

• на момент написания статьи версия Java 1.2 не поддерживалась ни одним навигатором, даже HotJava;
• версия Java 1.1 поддерживается в Internet Explorer весьма условно, есть проблемы в реализации некоторых прикладных программных интерфейсов, например, RMI;
• только сравнительно недавно Java 1.1 стала поддерживаться в Netscape Navigator;
• качество встроенной в Netscape Navigator виртуальной Java-машины – тема отдельного разговора;
• три конкурирующих несовместимых (и постоянно развивающихся) стандарта безопасности аплетов (от JavaSoft, Netscape и Microsoft) крайне затрудняют создание универсальных (рассчитанных на произвольного пользователя) аплетов;
• созданный JavaSoft Java 1.2 Plug-in следует рассматривать как спасательный круг, брошенный корпоративным разработчикам и администраторам систем, но отнюдь не как средство, которое принесет Java 1.2 на компьютеры миллионов пользователей Интернет.

Java постепенно уходит из Интернет, по крайней мере, на нынешнем витке развития. Об этом свидетельствует и направление развития Java-платформы – "аплеты", созданные средствами JDK 1.2, требуют для сносной работы мощнейших компьютеров и очень быстрых каналов связи. Простенький FTP-клиент, написанный на Java и требующий для своей работы не менее 64 Мб оперативной памяти, это не страшилка на ночь, а реальный факт, реальный коммерческий продукт. Вызывает недоумение и нестыковка действий команд Java-разработчиков из Netscape и JavaSoft.

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

Текущее состояние Java-технологии с корпоративной точки зрения

Использование Java для создания серверных приложений

Общие соображения

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

• многоплатформность особенно важна именно для серверных приложений, так как в этой области, к счастью, пока не наблюдается монополии;
• программные интерфейсы Java сейчас развиты настолько, что позволяют решать стандартным образом практически любые прикладные задачи, не требующие низкоуровневого взаимодействия с аппаратурой;
• достигнута неплохая надежность работы серверных приложений (автор лично убедился в возможности создания серверного приложения, выполняющего действия ежесекундно круглые сутки в очень жестком режиме, без каких-либо сбоев и зависаний);
• удобный механизм многопотоковости облегчает создание приложений, обслуживающих одновременно множество пользователей (реализовать Corba-сервер, обслуживающий в многопотоковом режиме множество параллельных клиентских подключений, оказалось гораздо проще при помощи Java, а не C++, причем Java-программа обычно получается надежнее из-за меньшего, в среднем, числа допускаемых программистом ошибок);
• практически снята проблема скорости работы серверных приложений. Во-первых, сама технология стала достаточно зрелой и последние версии JVM, оснащенные к тому же JIT-компиляторами, предоставляют весьма эффективную среду выполнения. Во-вторых, скорость работы серверного бизнес-приложения, в основном, зависит от проработки архитектуры приложения и качества ее воплощения в программный код, а в этой области Java является, возможно, наиболее адекватным средством. В-третьих, скорость работы корпоративных бизнес-приложений, в первую очередь, зависит от эффективности взаимодействия с СУБД. С появлением нового поколения JDBC-драйверов необходимая эффективность гарантирована;
• на сервере не так остра проблема объема потребляемой оперативной памяти;
• основная проблема внутренней корпоративной разработки – преодоление хаотичности действий отдельных разработчиков и команд разработчиков – в значительной степени решается с помощью присущего Java-технологии жесткого подхода к стандартизации и реализации программного интерфейса;
• Java идеально подходит для создания промежуточного, связующего ПО, осуществляющего взаимодействие различных, часто унаследованных систем, чему особенно способствуют такие качества Java, как многоплатформность и развитые коммуникационные средства;
• именно в серверных приложениях, не загроможденных реализацией пользовательского интерфейса, наиболее ярко проявляются достоинства Java как языка программирования (в первую очередь, стройность и простота). Скорость и простота написания приложений весьма важны для корпоративных разработчиков, постоянно находящихся в цейтноте и зачастую не обремененных большим программистским опытом;
• важный фактор – широкая поддержка серверных Java-технологий всеми заметными производителями СУБД, серверов приложений и мониторов транзакций.

Наблюдения за развитием Java показывают, что в настоящее время JavaSoft больше внимания уделяет именно серверной платформе. Например, вышедшая недавно Java 2 (старое название – Java 1.2) демонстрирует завидные достижения в области производительности и масштабируемости серверных приложений, но изобилует проблемами, связанными с работой на клиентской стороне. Качество серверных технологий, встроенных в Java 1.2, заставляет настойчиво рекомендовать использовать именно этот вариант для серверов приложений.

Корпоративные серверные технологии

Удаленный вызов методов (RMI)

RMI является зрелой и практичной технологией для организации взаимодействия Java-программ. Класс java.rmi.Naming и пакет java.rmi.registry предоставляют удобный облегченный аналог сервиса имен OMG Corba Naming Service, позволяющий эффективно вести поиск объектов. Несмотря на название "Удаленный вызов методов" (Remote Method Invocation), иногда удобно применять эту технологию и для локального взаимодействия Java-компонентов (из соображений унификации и глобализации). Например, при создании универсальных серверов, допускающих множество вариантов конфигурирования на этапе выполнения, разумно использовать RMI для организации взаимодействия всех компонентов системы, что позволит получить большую гибкость конечного программного продукта. Простые примеры использования RMI для взаимодействия объектов приведены в [5] и в приложении к данной статье.

Однако не все так просто при удаленном взаимодействии, особенно на низкоскоростных линиях связи. Коммуникации RMI опираются на программный интерфейс сериализации, что неоправдано с точки зрения эффективного использования пропускной способности сети (по крайней мере, при использовании стандартной реализации интерфейса Serializable). Поэтому, RMI имеет смысл использовать в локальных сетях и для локального взаимодействия. Лучше всего применять RMI для организации взаимодействия объектов в компонентной технологии (JavaBeans), где ярко проявляются такие достоинства RMI, как простота, унифицированность, прозрачность взаимодействия. При создании территориально распределенных систем предпочтительнее технологии более низкого (TCP/IP Sockets) или более высокого (Corba) уровней.

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

Представленная в JDK/JRE реализация RMI не отличается особой производительностью, это всего лишь "действующая модель". Компании-производители серверов приложений для Java часто предлагают собственные реализации RMI, настроенные на работу в условиях высокой нагрузки. Например, продукт WebXpress компании BEA Systems предоставляет изощренную и высококачественную реализацию RMI, основанную на оптимизированном интерфейсе Serializable и усовершенствованном механизме серверной многопотоковости. Резервы повышения производительности RMI хорошо описаны в [4].

Возможно, однако, что сейчас наблюдается процесс принципиального улучшения производительности стандартной Java-платформы. Это имеет место, по крайней мере, в области поддержки большого числа клиентов на сервере. И личный опыт автора, и результаты независимых тестов (см. [1]) показывают, что новая версия Java 1.2 способна уже в стандартом варианте (без коммерческих расширений) поддерживать действительно большое число клиентов, одновременно работающих с сервером приложения. Пока, к сожалению, таким выдающимся качеством может похвастать только версия Java 1.2 для Solaris, но есть надежда, что качественные реализации для Win32 и Linux не за горами. Личный опыт автора говорит о том, что несколько сотен подключений по протоколу RMI на платформах Solaris и Windows NT не вызывают никаких особых проблем уже для стандартной установки Java 1.2 (без продуктов третьих фирм), а на платформе Linux такая степень масштабируемости становится доступна после настройки параметров ядра системы.

Большую работу по повышению производительности Java-платформы проводит корпорация IBM, сделавшая общедоступной собственную реализацию JDK для Win32. Эта реализация отличается хорошей масштабируемостью (хотя и уступает JDK 1.2 от JavaSoft для Solaris) и повышенной производительностью.

Corba

В настоящее время Corba является наиболее адекватным средством создания распределенных корпоративных систем. Данная технология сочетает относительную простоту (особенно в сравнении с DCOM), мощность и универсальность подхода. Мы, однако, не будем рассматривать Corba как таковую, а представим свои соображения о связке Java-Corba.

Среди существующих языков программирования Java является наиболее подходящим средством выражения конструкций Corba. Для доказательства достаточно сравнить спецификации "Mapping of OMG IDL to C++" и "Mapping of OMG IDL to Java". Невооруженным глазом видно, что попытка "натянуть" концепцию Corba на C++ выглядит весьма искусственной и вынуждает пользоваться самыми сложными и сравнительно новыми конструкциями C++. Напротив, Java-интерфейсы Corba выглядят простыми и естественными.

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

Большим неудобством программирования Corba-приложений на C++ является то, что очень легко допустить ошибку при манипулировании указателями на Corba-объекты из-за сложного использования конструкторов присваивания в классах C++, автоматически создаваемых IDL-компилятором. Подобная проблема полностью отсутствует в программах на Java.

На примере Corba-программ особенно ясно видна архаичность (в сравнении с Java) языка C++. В настоящее время многие поставщики Corba-реализаций предлагают средства создания Corba-приложений (как серверных, так и клиентских) с помощью Java. Это, например, такие продукты, как M3 (BeaSystems), Visibroker (Inprise), OrbixWeb (Iona), NetDynamics (Sun Microsystems), Orbacus (OOC, Inc.).

Огромным плюсом Corba с точки зрения разработчика является наличие спецификаций (и реализаций) стандартных сервисов, соответствующих часто используемой в приложениях функциональности. Автору известны следующие доступные для использования в Java-приложениях сервисы (реализованные в коммерческих продуктах): Naming Service, Event Service, Transaction Service, Property Service, Security Service, Life Cycle Service, Trading Object Service (список, конечно, не полон).

К сожалению, не все производители строго следуют спецификациям на сервисы и часто добавляют от себя всякие "усовершенствования", что размывает единое поле Corba. Например, компания Inprise изрядно "постаралась", добавив в Visibroker функциональность, дублирующую Naming Service и Event Service, но несовместимую со спецификациями OMG (правда, для Visibroker отдельно предлагается и стандартная реализация этих сервисов). С точки зрения программиста-практика это, по меньшей мере, странно и неудобно. Как образец стандартности заслуживает одобрения объектный брокер Orbacus, практически не внесший никаких "улучшений" в спецификации OMG.

Примером специализированного брокера объектных запросов является M3 (BeaSystems). Этот продукт в значительной степени сохранил совместимость со спецификациями OMG, а необходимые расширения, в основном, добавлены к окружению времени выполнения совершенно прозрачным образом для разработчиков приложений. Это единственно правильный способ добавления расширений к стандарту в тех случаях, когда они необходимы. В случае M3 расширения оправданы, так как продукт имеет специфическую область применения – это сверхбольшие приложения с огромным количеством распределенных объектов.

Популярности использования связки Corba-Java, несомненно, будет способствовать включение в JDK 1.2 основ Corba-технологии (простой объектный брокер и Naming Service) как неотъемлемой части. Конечно, для больших распределенных приложений этого недостаточно, и нужно использовать коммерческие продукты, но разработчики смогут изучить эти технологии и составить свое мнение о них.

Следует отметить такое преимущество Corba перед RMI, как возможность в одной программной системе использовать модули, написанные на разных языках программирования. Например, из клиентской программы, написанной на Visual C++, с помощью стандартных средств Corba можно обращаться к реализациям серверных объектов, созданных на Java, причем способ вызова удаленных объектов не зависит от того, на каком языке программирования они написаны. Что же касается RMI, то в настоящее время это технология исключительно для Java.

Corba имеет и такой существенный плюс, как стандартизация реализаций брокеров запросов и протокола их взаимодействия – IIOP (Internet Inter-ORB Protocol). Это позволяет использовать различные брокеры запросов в различных подсистемах большой программной системы, что может быть очень выгодно для ее оптимального построения. Например, можно применять встроенный в Netscape Navigator Visibroker для клиентского приложения и одновременно использовать M3 как мощный масштабируемый брокер для серверного приложения.

К великому сожалению, пока не видно продвижения к стандартизации взаимодействия сервисов OMG Corba, из-за чего различные брокеры запросов не могут совместно использовать, например, Naming Service, Event Service и т.п.

Как и в случае RMI, реализация брокера запросов в Java 1.2 далеко не оптимальна по производительности. Например, сейчас в этой реализации имеется только одна модель управления потоками на сервере приложений, когда на каждый запрос создается отдельный поток и по окончании запроса он уничтожается. Конечно, такая модель создает неоправданную нагрузку на серверную систему. Для серьезных приложений лучше использовать специальные реализации Corba для Java (см. выше). Продвинутые коммерческие реализации (Visibroker, M3, Orbacus) могут задействовать модель "пул потоков", когда некоторое заранее определенное число потоков распределяется между запросами. При этом не происходит создания и уничтожения потоков для обработки клиентских запросов.

JDBC, JSQL

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

Некоторые современные реализации стандарта JDBC полностью отвечают потребностям корпоративных разработчиков. Автор проводил сравнительное тестирование скорости доступа к СУБД из программы на Java и из программы на C. Использовались: СУБД Oracle 8, "родной" драйвер JDBC, препроцессор и библиотеки Embedded SQL/C (PRO-C). Платформа тестирования – SPARC Solaris 2.5.1, процессор UltraSPARC 147 МГц. Сервер СУБД и программа-клиент СУБД работали на одном компьютере, чтобы исключить погрешность, вносимую сетевыми взаимодействиями. Простые SQL-запросы по выборке нескольких строк из таблицы размером 200000 записей, по индексированным столбцам, требовали в среднем от 0.002 до 0.01 секунды. Это близко к аналогичным показателям для программ, созданных с помощью PRO-C.

Приведенные данные показывают, что разница в производительности невелика и непринципиальна, а для SQL-запросов средней и большой сложности вообще незаметна. Это, в сочетании с высокой надежностью современных драйверов JDBC, позволяет считать Java подходящим средством для реализации серверных приложений, взаимодействующих с СУБД.

Имеются и примеры противоположного рода, когда реализация JDBC явно неадекватна, однако, есть надежда, что все производители драйверов JDBC со временем "подтянутся" до приемлемого уровня.

Использование JDBC в Java-программах аналогично использованию ODBC в программах на C со всеми вытекающими последствиями для удобства написания. "Многословность", присущая JDBC, особенно неприятна в больших проектах, имеющих и без того сложные исходные тексты. Для исправления этого положения компанией Oracle была выдвинута инициатива стандарта JSQL, который представляет собой спецификации препроцессора Java/SQL и, фактически, является аналогом Embedded SQL/C. Этот стандарт был поддержан остальными производителями СУБД и в настоящее время процесс написания программ на Java, взаимодействующих с СУБД, заметно упростился.

Использование Java для создания клиентских приложений

Общие соображения

К сожалению, в настоящий момент ресурсы, необходимые для эффективной работы Java-программ, заметно превышают возможности типового современного компьютера клиента (по крайней мере, в России). Минимальные реальные требования к клиентской платформе для Java 1.2 таковы: процессор не слабее Pentium II 200 МГц, память 32 МБ. Рекомендуемые параметры в 2-3 раза выше.

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

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

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

Корпоративные клиентские технологии

Swing

До появления пакета Swing пользовательский интерфейс Java-программ был весьма аскетичным. Сравнение средств пакета java.awt с богатством такой библиотеки, как MFC (из комплекта Microsoft Visula C++), было, мягко говоря, не в пользу Java. Появление Swing коренным образом изменило ситуацию. Java-разработчики теперь получили возможность, не используя продукты третьих фирм, создавать программы с профессиональным интерфейсом.

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

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

К сожалению, имеется одна крайне неприятная вещь: Swing невозможно использовать в России, начиная с версии Java 1.2! Русские буквы просто не показываются на платформе Windows 95 (хотя под Solaris и Linux, вроде бы, все нормально). Этот "сильный ход" вызывает, по меньшей мере, недоумение у отечественных разработчиков. Данная проблема была известна еще до окончательного выхода Java 1.2, но не была исправлена ни в окончательной редакции, ни в вышедшей совсем недавно версии Java 1.2.1. JavaSoft хранит застенчивое молчание по поводу такого "экспортного ограничения", а отечественным разработчикам приходится по-прежнему пользоваться Java 1.1.

Программный интерфейс печати (Printer API)

Корпоративное приложение, взаимодействующее с пользователем и не использующее вывод информации на печать, является большой редкостью. До появления версии 1.2 Java часто справедливо критиковалась из-за трудности взаимодействия программного кода с принтером. Сейчас эта проблема в значительной степени решена с помощью нового пакета java.awt.print.

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

Другая проблема: новый интерфейс, как и Swing, не поддерживает русских кодировок символов. По крайней мере, тут JavaSoft последовательна в своей политике.

Еще раз RMI

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

Такое многообразие похожих способов взаимодействия (Corba, RMI, RMI поверх IIOP) в Java может вызвать недоумение. Однако история возникновения подобного положения весьма прозрачна. Вначале JavaSoft разработала собственный стандарт взаимодействия объектов, и это был RMI. Затем, встретив трудности на пути продвижения Java как средства создания корпоративных приложений, компания была вынуждена заняться поиском союзников в этом нелегком деле. К тому времени уже произошла поляризация производителей: часть поддерживала стандарт OMG/Corba, часть – OLE/DCOM. Понятно, что новый стандарт – RMI – был встречен весьма прохладно. JavaSoft пришлось выбрать один из двух лагерей (легко догадаться, что это был лагерь Corba). Дальнейшее развитие пошло по линии увеличения роли Corba в Java-технологии. Вначале появилась собственно реализация Corba в Java 1.2. Затем RMI начал видоизменяться в сторону Corba. С выходом RMI/IIOP данная технология превратилась в облегченное средство работы с Corba-объектами. Скорее всего, это хорошо, как для Java, так и для Corba. Остается только дождаться включения RMI/IIOP в стандартный JDK.

Еще раз Corba

Corba-клиент свободен от недостатков, присущих RMI. На уровне протокола IIOP все реализации Corba совместимы. Мы легко можем заставить взаимодействовать аплет под управлением Netscape (в который встроены клиентские библиотеки брокера запросов VisiBroker) и сервер под управлением Java 1.2, имеющий собственный брокер. Кстати, тот факт, что в Netscape Navigator встроен брокер запросов, делает его более удобным средством в корпоративных приложениях, чем Internet Explorer, такого брокера не имеющий, и не предоставляющий никаких средств интеграции собственной DCOM-модели с Corba.

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

Надстройки Java 1.2 для навигаторов

Осознав, что поддержка Интернет-навигаторами новых версий Java задерживается, JavaSoft решила переломить ситуацию и взять процесс под свой контроль. Кое-что в этом деле удалось. Java 1.2 plug-in позволяет получить полную поддержку Java 1.2 в свежих версиях навигаторов. Следует отметить удобство и продуманность процесса установки этого продукта. Предусмотрена автоматическая установка надстройки (при ее отсутствии на компьютере клиента) по локальной сети (для Internet Explorer). Это позволяет программистам предприятия одним махом решить проблему версий Java. Поместив где-нибудь в корпоративной сети на сервере Java 1.2 plug-in, разработчики и администраторы могут быть уверены, что при первом запуске аплета, созданного для Java 1.2, на компьютер пользователя будет автоматически установлена соответствующая версия виртуальной машины. Очень удобно. Но есть недостаток, неожиданный для Java, – полное отсутствие многоплатформности: данная надстройка существует только для Win32!

Общие технологии

Интерфейс безопасности (Security API)

Для решения проблемы аутентификации и шифрования компания JavaSoft разработала набор спецификаций. Это пакеты java.security и javax.crypto. Первый из них организует общий "каркас" системы защиты приложений и содержит реализацию протоколов электронной подписи "по умолчанию", от JavaSoft. Второй набор реализует протоколы шифрования данных и подпадает под экспортные ограничения США, поэтому он не входит в стандартный дистрибутив Java. Резиденты США получают эту реализацию непосредственно от JavaSoft, остальной мир – от независимых производителей.

Модель "поставщиков услуг безопасности", примененная JavaSoft, позволяет использовать реализации протоколов защиты как сменные модули, причем в одной программе можно переключаться между ними. Совершенно свободны производители и в выборе используемых алгоритмов шифрования и электронной подписи. Обычно это стандартный набор – RSA, DSA, DES плюс какие-нибудь дополнительные алгоритмы. Например, австрийская фирма IAIK среди алгоритмов шифрования предлагает и российский ГОСТ симметричного шифрования с ключом 256 бит.

Corba, RMI, сервлеты как средства создания сложных многоуровневых распределенных приложений, не ограниченных стандартной жесткой схемой "клиент-сервер"

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

Рассмотрим случай, когда серверное приложение должно вызывать в клиентском некоторые асинхронные события. Например, перед операционистом в банке должно возникать сообщение о приходе денег на определенный счет. Это, конечно, можно сделать с помощью периодического опроса сервера клиентом, но если у нас есть, допустим, 100 операционистов, контролирующих по 100 счетов каждый, то нагрузка на сервер при таком периодическом опросе будет немалой и совершенно неоправданной. Проблему сообщений клиенту легко решить с помощью Event Service (сервис передачи сообщений) при использовании Corba как средства взаимодействия, однако, возникает сразу несколько проблем, делающих такое решение далеко не универсальным:

• оно непригодно в случае использования RMI;
• оно заставляет использовать одну и ту же реализацию брокера запросов и на клиенте, и на сервере (выше мы упоминали, что реализации сервисов, в том числе и Event Service, для разных брокеров несовместимы);
• нельзя использовать реализацию брокера, не имеющую Event Service (например, ее не имеет в стандартной поставке брокер из JDK/JRE 1.2);
• такое решение ограничивает нас только асинхронными сообщениями, однако, могут понадобиться и сообщения синхронные. В нашем примере это может быть необходимость спрашивать у операциониста разрешения о снятии денег со счета (то есть сервер спрашивает у клиента: "а можно ... ?").

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

Как Corba, так и RMI позволяют реализовать подобную схему без всяких специальных усилий. Таким образом, мы решаем все четыре проблемы, связанные с применением Event Service. Пожалуй, только с появлением Java такие типы взаимодействия для "клиента" и "сервера" стали простыми и естественными.

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

В [4] приведены различные схемы организации "обратного взаимодействия".

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

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

Можно усложнить схему и "вглубь", когда количество уровней программной системы "клиент-сервер" становится больше двух (не считая сервера базы данных). При этом приложения в средних уровнях являются клиентами для более низких уровней и серверами – для более высоких. Например, на этом принципе основана Java-архитектура в компании Sun Microsystems (см. [2]).

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

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

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

Самым интересным для нас является второй уровень – уровень "суррогатного клиента". Этот "клиент" чаще всего создается с помощью Web-сервера и специальных расширений для него, позволяющих вместо CGI-процедур запускать Java-программы (сервлеты). Сервлеты поддерживаются таким Web-сервером, как Apache, а это примерно 60% всех серверов Интернет (см. http://www.netcraft.com). При использовании сервлетов нет необходимости даже в наличии Java на компьютере пользователя – достаточно обычного Web-навигатора.

Заключение

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

Очень важна технологическая сдержанность JavaSoft: скорость роста ресурсных требований Java-платформы не должна быть выше скорости роста "вооружения" типового компьютера. Очень многие Java-разработчики были неприятно поражены степенью роста "прожорливости" Java 1.2 по сравнению с Java 1.1.

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

Распространению Java в компаниях не способствует "проблема Linux". Автор сформулировал бы ее так: "самая перспективная ОС имеет самую плохую реализацию Java-машины". Различные независимые исследования, например, [3], подтверждают, что в настоящее время Linux становится одной из основных ОС на предприятиях, с наиболее высоким процентом роста инсталляционной базы.

К сожалению, качество реализации JVM для Linux до сих пор удручающее, и это не дает возможности Java "оседлать" волну популярности Linux. Невысокое качество JVM для Linux подтверждают как личный опыт автора, так и данные независимого тестирования (см. [1]). Никакая крупная компания – ни JavaSoft, ни IBM – не производит JVM для Linux. Для IBM это был бы особенно естественный шаг, она объявила о полной поддержке Linux в корпорациях и уже выпускает JVM для множества платформ – OS/2, Win32, AIX, MVS, OS/400 и имеет в этом деле большой опыт.

Java необходима для Linux, поскольку помогает устранить такие изначально присущие Linux недостатки, как:

• отсутствие реальной компонентной технологии (JavaBeans тут как нельзя более кстати);
• сложность создания пользовательского интерфейса. Программирование для X Window по плечу немногим специалистам. Кроме внутренне присущего Java удобства построения графического интерфейса, имеется множество удобных визуальных редакторов такого интерфейса.

Несмотря на все сложности развития Java, автор совершенно согласен с высказанной в [2] мыслью, что "Java, несомненно, культовая технология". Направление развития компьютерных технологий в первой половине 90-х годов вызывало откровенное недоумение у значительной части специалистов, на разных уровнях выражавшееся по-разному. На "школьном" уровне появился бесхитростный "пролетарский" лозунг "Windows Must Die", на "студенческом" организовалась команда разработчиков Linux, "академический" и "корпоративный" слои профессионалов нашли свое выражение в Java.

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

Автор выражает благодарность Владимиру Николаевичу Родионову (Java Certified Programmer) за консультации и обсуждение сложных вопросов.

Литература

1. Neffenger J. – Which Java platform is fastest, most scalable? – JavaWorld, 1999, March
2. Александр Таранов , Владимир Цишевский – Java в три года – Jet Info, 11-12, 1998
3. Dan Kusnetzky , Jean S. Bozman , William Peterson – Linux Operating System Market Overview – Отчеты IDC (International Data Corporation), W18662
4. Dan Kusnetzky , Jean S. Bozman – What's Happening in Linux Servers? – Отчеты IDC (International Data Corporation), W18831
5. Dan Kusnetzky , Jean S. Bozman – Strategies for Windows NT in the Enterprise – Отчеты IDC (International Data Corporation), W18426
6. A. Krumel – Write high-performance RMI servers and Swing clients – JavaWorld, 1999, April

Статья опубликована в журнале Jet Info, №5, 1999 г.