Java под парами

Язык Java компании Sun выбрал курс между Web и не отмеченным на карте морем бесчисленных апплетов. Поднимается прилив распределенных компонентных архитектур...

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

Это кажется несколько странным. Если у вас есть опыт общения с Web, то вы должны знать, что язык разметки гипертекста HTML позволяет делать с обычными документами, а что нет. Эта графика (или более точно - комбинация графики) - небольшая толика интеллекта, посланная вашему компьютеру и теперь выполняемая локально ЦПУ. Иными словами, вы увидели программный компонент, распространяемый по Internet.

Чтобы не ходить вокруг да около - это был Java, язык программирования, разработанный компанией Sun Microsystems, и вы видели его в среде Web, в которой он стал наиболее горячей и популярной темой со времен Mosaic.

Из трех технологий распространения компонентов в сети - OpenDoc, Network OLE и Java, последняя наиболее приемлема и, кроме того, именно ее даже относительно трезвые аналитики пророчат роль могильщика Microsoft.

Рассматривая в прошлом номере (см. "Глубины OpenDoc" в апрельском номере) OpenDoc, мы, имея на то веские основания, назвали архитектуру OpenDoc наилучшей для распространения полнофункциональных объектов. Абсолютно справедливо утверждение о том, что технология OLE компании Microsoft имеет огромную рыночную инерцию и, по крайней мере, в среде Windows ей обеспечено активное использование для распространения компонентов, ведущих себя как объекты. Однако, когда разговор заходит о Java, легко ошибиться, сделав вывод, что речь идет всего лишь еще об одном языке программирования. Ничего революционного, просто язык.

Если смотреть под определенным углом зрения, то Java - это усовершенствованный C++ с некоторыми сетевыми добавлениями. Он не так быстр, как C++, по крайней мере в его настоящем виде. О нем можно много говорить как о языке программирования и инструменте разработчика.

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

ИЗМЕНЕНИЯ В ЯЗЫКЕ С

Если OpenDoc представляет собой чистокровное решение для распространения программного обеспечения в сети, то Java - это прагматическое решение. Java далек от тех благородных подвигов, которые OpenDoc и его "верный оруженосец" Common Object Request Broker Architecture (CORBA) вознамерились совершить. OpenDoc - это архитектура, среда, вселенная, тогда как Java - всего лишь язык программирования. Java решает задачу межплатформенного перехода, а CORBA - задачу прозрачности между множеством узлов. Java позволяет реализовав объект однажды, использовать его на различных платформах, однако он не позволяет иметь прозрачный доступ из данного объекта к объектам на других платформах.

CORBA позволяет вызвать процедуру (метод объекта), не заботясь о том, локально или глобально она выполняется. Но если доступ к методам объекта может быть открыт в CORBA всем, то реализация объектов CORBA, во всяком случае сегодня, зависит от платформы.

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

ГРУЗ JAVA

Java - близкий родственник C++. Он отказался от пары-другой свойств C++, оборачивающихся недостатками, когда дело касается работы в распределенной среде. Короче говоря, эффективно управлять памятью в C++ чересчур сложно, а неправильно употребить указатель очень даже просто. Результат - ненадежность: очень много ошибок.

В Java управление памятью (в частности нахождение использованных и потерянных адресов памяти) производится автоматически. Использование указателей на адреса памяти или использование косвенных ссылок на хранимые по этим адресам значения попросту не допускается. Такой язык позволяет создавать код, исполняемый на виртуальной машине, соответствующей ряду аппаратных платформ. До настоящего времени аппаратные платформы включали Sun, Windows NT и Windows 95, а вскоре к ним присоединятся Macintosh и Windows 3.1. (Отметим, однако, что это не простая задача для 16-разрядных Windows, так как Java ориентирован на многопоточную обработку, а 16-разрядные Windows ее не предусматривают.)

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

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

Очевидное преимущество языка - независимость от платформы. Что бы вы ни написали на Java, программа будет выполняться в любой среде, в которой реализован интерпретатор. Другое, но менее очевидное преимущество использования байтовых кодов - возможность размещения большего количества команд в меньшем числе модулей. Если вы загружаете код по относительно медленной среде передачи, например по Internet, загрузка и окончательная компиляция небольшого по объему кода происходит быстрее, чем передача и выполнение внутреннего кода.

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

ПЛЕМЯ АППЛЕТОВ

Помимо автономных программ есть еще распределенные программы - апплеты. Они посылаются серверами Web программам просмотра со встроенными интерпретаторами Java.

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

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

Такой подход несколько отличается от попыток использования существующих языков для создания загружаемых по сети и затем выполняемых приложений. Возьмем, например, Perl (Practical Extraction Report Language). Хакер, воспользовавшись тем, что системная утилита получает параметры из командной строки, способен взломать защиту. Если в локальной системе выполняется программа на C или C++, то опытный программист может воспользоваться рассогласованием массивов для доступа к памяти, лежащей за пределами массива. Таким образом, злоумышленник сможет прочитать не предназначенные для посторонних глаз области памяти или, что еще хуже, записать в них свою информацию. Ничто в C и C++ не способно предотвратить такое несанкционированное использование памяти.

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

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

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

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

Как заметил недавно Рей Уолдин, ведущий инженер по проверке качества в антивирусной группе Symantec, в группе новостей comp.lang.java: "Все основывается на допущении, что реализованная система защиты будет абсолютно надежна".

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

БИЗНЕС-АССОРТИ

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

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

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

Вопрос защиты имеет и свою обратную сторону. "Как программистам сохранить свои секреты? - спрашивает Барлетт. - Код апплетов сам по себе не защищен. Заинтересованному лицу не составит труда восстановить исходный код. Например, Sun предоставляет инструмент, javap, позволяющий декодировать практически всю информацию о классе. Инструменты других разработчиков, например широкодоступный в Internet обратный ассемблер байтового кода, еще более упрощают эту задачу.

Ким Полез, менеджер по продуктам для Java, замечает по этому поводу, что при желании на настольном компьютере декодируется все что угодно: "Двоичный поток всегда может декодировать, если очень захотеть".

По мнению Барлетта, это замечание уводит от сути дела: "Дело вовсе не в сравнении одних апплетов с другими, - говорит он. - Java предлагает программисту определенную структуру программирования. Эта структура сама по себе упрощает декодирование и делает его более вероятным".

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

Даже пиратство - одна из основных проблем - не охлаждает энтузиазм разработчиков и поставщиков, готовящих инструменты разработки. Компания Borland, восставшая практически из пепла благодаря успеху своего инструмента проектирования Delphi, поспешила заявить о разработке инструментов под кодовым названием Latte. Symantec подсуетилась и перепрофилировала свою среду С++, так что программа просмотра исходного кода теперь понимает синтаксис Java. Это дополнение под названием Cafe представляет прекрасный графический интерфейс для редактирования и просмотра исходного кода.

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

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

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

КОЛДОВСКОЕ ЗЕЛЬЕ

Java не имеет сама по себе какого-либо объектно-ориентированного средства для вызова методов объектов по сети прозрачным образом. Однако ничто в Java не препятствует его включению в какую-либо имеющуюся среду шины объектов. Sun вместе с PostModern разрабатывают продукты для интерфейса апплетов на Java с протоколом Internet Inter-ORB Protocol (IIOP) в архитектуре CORBA.

Президент PostModern Енс Кристиансен так описывает продукт компании: "Black Widow ("Черная вдова") генерирует код Java по спецификации интерфейса". Эта способность естественным образом описывать интерфейс является одной из сильных сторон CORBA. "С одной стороны, генерируется код Java для клиента, выполняющийся как стандартный апплет в выбранной пользователем программе просмотра, работающей с Java; с другой - клиентской стороны генерируется каркас для различных вызовов функций".

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

"Этот инструмент, - считает Кристиансен, - получился таким мощным потому, что обходятся протоколы http/CGI (протокол передачи гипертекста/интерфейс доступа к внешним данным). Кристиансен замечает, например, что обычный порядок вызова можно поменять на обратный, поместив объект CORBA в клиентский апплет и вызывая этот объект с сервера, только когда предопределенные события (такие, например, как получение сообщения об изменении цены на акции) происходят на сервере. "Апплеты Java довольно малы, а если вы хотите, чтобы они делали что-нибудь нетривиальное, то они должны быть связаны с распределенными объектами".

Еще одна из интересных возможностей Black Widow состоит в том, что объекты CORBA на сервере могут тиражироваться на другие серверы. Как следствие, система обладает избыточностью и повышенной степенью надежности.

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

ВАМ С МОЛОКОМ?

Не вызывает никакого сомнения, что Java может использоваться для создания компонентов. Java выглядит как довольно мощный претендент на место наследника С++ в программистском мире. И на эту позицию у Microsoft нет достойных претендентов. Visual Basic имеет свои преимущества, но он не прижился в мире С++. Не следует, однако, забывать, что Microsoft, благодаря технологиям Network OLE и Component Object Model, достаточно конкурентоспособна в мире распределенных компонентов.

Пока остается неясным, какую позицию Microsoft займет в отношении Java. Компания остается верна своим приоритетам, продвигая OLE и Network OLE. Однако Microsoft приобрела у Sun лицензию на Java для не совсем пока понятных целей.

Заявление Microsoft о намерении приобрести лицензию на Java было встречено сообществом Internet с неподдельным изумлением. В паре-другой циничных почтовых сообщений по тематике Java говорилось, будто Microsoft пошла на соглашение с Sun, чтобы утихомирить рыночных экспертов, шумно радующихся тому факту, что Билл Гейтс на этот поезд явно опоздал. Однако это заявление позволило Java окончательно утвердиться в качестве заметного игрока во вселенной Web, по крайней мере на ближайшие два года. В результате предположение, что апплеты Java будут основным проводником распределенных объектных компонентов через Internet в краткосрочной перспективе, становится весьма вероятным.

---

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

В World Wide Web можно найти богатейшую документацию по Java. В первую очередь, это, конечно, узел Sun: http://java.sun.com. Вместо того чтобы копаться в новостях comp.lang.java, загляните лучше в еженедельную сводку в узле Digital Expresso (http://www.io.org/mentor/J_Notes.html). Список часто задаваемых вопросов можно найти в http://sunsite.unc.edu/javafaq/javatutorial.html.