Виртуальные машины в битвах гигантов

В технологии Inferno есть все, чтобы считать ее сильнейшим кандидатом на роль единой масштабируемой архитектуры для применения встроенных устройств в распределенных сетевых средах. Непонятно только, почему кандидатуру Inferno на эту роль пока никто не рассматривает.

Пейзаж после битвы

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

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

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

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

Благодаря архитектурной независимости интерфейса Java Beans элементы пользовательского интерфейса, методы связи с базами данных и другие невизуальные функции, написанные и откомпилированные на Java, встраиваются в Netscape Navigator и SuiteSpot, Borland Delphi, Microsoft Visual Basic как в контейнеры, исполняясь внутри этих приложений.

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

Группой, в начале 90-х специально сформированной для этой цели в недрах компании Sun, был за полтора года с нулевой отметки создан прототип нынешней Java-машины, реализованный на аппаратной платформе Star7 - миниатюрной SPARC-станции с интерфейсами беспроводной инфракрасной и радиосвязи и поддержкой звука. Считалось, что ее основное назначение - интерактивное телевидение и игры. Но в 1994 году проект тогдашней Java был признан неудавшимся и не получил промышленного применения.

Интересно, что в этом проекте не было предусмотрено никаких графических средств (что само по себе удивительно, учитывая, что в его создании принимали участие люди, фактически определившие такие оконные стандарты, как OpenLook и NeWS). Попытки реанимировать проект, направив его в другое русло, продолжались, и тут проявилась мощь Java как среды программирования: была спроектирована и за очень сжатые сроки доведена до ума иерархия классов java.awt.*, суммирующая общие для оконных менеджеров X11-Motif, Windows и Mac функциональные возможности, а в 1995 году уже состоялась историческая массовая акция приобретения лицензий на технологию Java более чем десятком всем известных компьютерных компаний. После этого события развитие Java пошло своим путем, в сторону рынка настольных систем, где центральное место занимает программная поддержка пользовательского интерфейса и тяжеловесных клиент-серверных сеансов, о чем говорит прежде всего эволюция библиотек классов от JDK 1.0. к JDK 1.1.7. Правда, в последнее время появились облегченные спецификации Personal Java и Embedded Java, на подходе и вторая версия Java Card; все это - просто более узкие подмножества библиотек классов, входящих в JAE (Java Application Environment), которыми располагают клиенты разной "толщины" помимо голой виртуальной машины. В соответствии с мощностью клиента и осуществляется разработка приложений под соответствующим JAE. Почти полностью уйдя в "толстые" приложения и пытаясь сохранить масштабируемость, Java вводит разномасштабные целостные иерархии классов в библиотеках времени исполнения.

Охотники заряжают ружья

Пока индустрия встроенных систем ищет экономически оправданную распределенную вычислительную технологию, пригодную для разделяемого использования разнокалиберных сетевых ресурсов, она мало подвержена моде в своем выборе. Из около сотни встроенных систем, перечисленных журналом "Real Time World" как самые популярные, подавляющее большинство, по данным обзоров это журнала, реализовано на ассемблере и традиционном C, без использования объектно-ориентированных средств. Программа, написанная для некоторого устройства, при изменении рабочих характеристик устройства заменяется полностью переписанной программой.

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

Продукция компании Wind River Systems (крупнейшего производителя систем реального времени для активного сетевого оборудования) известна почти каждому, кто входил телнетом на автономный свитч или какой-либо из модулей сетевого концентратора, там его встречал пользовательский интерфейс старой доброй VxWorks, обожаемой сетевиками. Как раз эта компания десять лет назад стала широко использовать telnet, FTP, а затем NFS и протоколы оконных систем во встроенных системах, затем она же разработала интерфейсы в компонентной модели CORBA для сетевого управления своими встроенными системами, и вот теперь разработчиками Wind River поверх фирменной операционной системы VxWorks реализована виртуальная Java-машина с множеством инструментальных средств для создания встроенных Интернет-устройств. Сейчас уже практически все разработчики встроенных систем пытаются использовать возможности виртуальной Java-машины, работающей под существующими реализациями JavaOS и других ОС.

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

Основные препятствия на этом пути:

1. Большой объем виртуальной машины - низкая скорость интерпретации мобильного байт-кода.
2. Объектный сборщик мусора Java является помехой при построении приложений реального времени.

Примерами на пути преодоления этих препятствий являются успехи в создании виртуальных машин поверх RTOS (PORTOS, PERC, Chorus и некоторых других) и, наконец, появление нескольких JavaOS.

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

Одной из таких драматических историй является замысел и создание Java-технологии. История получила известность из-за связанной с ней беспримерной рекламной компании. Скорее всего работы над воплощением проектов, сходных с Java по идейному содержанию и времени замысла - например, Oberon совместно с языком Компонентный Паскаль и системой PORTOS (Hard RTOS) или Inferno в совокупности с языком Alef, а затем с Limbo, - также с самого начала происходили как нерядовые явления. Ведь среди их авторов - выдающиеся люди, уже прославившиеся созданием, к примеру, таких продуктов, как языки C и C++, операционная система Unix, среда исполнения Juice.

Ложная скромность

Проект Inferno, родившийся в недрах Lucent Technologies, интересен для нас не только поразительным фактом отсутствия сведений о нем в местном представительстве Lucent. В конце концов, каждый, кто заполнил регистрационную форму на www.lucent.com/inferno (и чей домен прописан на сайте Lucent) и пообещал не реэкспортировать Inferno в некоторые страны, до которых от нас и так далеко, как до Луны, может получить ее вместе с возможностью с ходу начать разработку приложений в этой среде.

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

Мы все говорим о неких средах, а, по сути дела, Inferno 1.1, которую можно получить по Интернету (в процессе подготовки этой статьи стала доступной версия 2.0), - это операционная система на основе легко портируемого микроядра, способная функционировать в минимальной аппаратной конфигурации. Она написана на языке Limbo, компилируемом в мобильный объектный код для виртуальной машины, называемой Dis. Все эти названия являются зарегистрированными торговыми марками, и к ним ко всем в документации имеются соотнесения из "Божественной комедии" Данте, так что всюду присутствует "адская" символика. У нас подобное принято относить к характерной для американцев корпоративной дебильности, но все-таки проект Дантова Ада занимает выдающееся место в истории цивилизации по своей необъятности и выстроенности мельчайших деталей. Это контрастирует с суетностью мира кофейно-кулинарной символики Java.

Виртуальная машина Dis может быть либо непосредственно привязана к архитектуре процессора, и в этом случае исполнение мобильного объектного кода Limbo оптимизируется под данный процессор, либо - реализована через системные вызовы операционной системы, в гостях у которой находится Dis в качестве эмулятора. Последний вариант наиболее пригоден для создания мостов прикладного уровня, связывающих интерфейсы Inferno с объектными компонентами, загруженными в адресные пространства других операционных систем. Разные экземпляры виртуальных машин Inferno объединены друг с другом посредством Styx - системы передачи сообщений, словарь которых минимален, способной работать поверх протокола любого установленного соединения сетевого уровня.

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

В реализацию Limbo - языка программирования, на котором написана вся система Inferno, заложены ограничения, придающие асинхронно обрабатываемым событиям временную детерминированность исходя из требований работы системы в режиме реального времени. В частности, встроенный в Limbo сборщик мусора ведет себя значительно скромнее своего собрата из JVM по отношению к высокоприоритетным обработчикам событий. Для системы с "родной" ОС имеется компилятор Just -In-Time, производящий объектный модуль в машинных кодах. Из-за того что принцип виртуальной машины Dis не стековый, а трехадресный - типа "память-в-память", код JIT получается лишь в два раза объемистее результата компиляции функционально равнозначного C-кода. По той же причине Dis гораздо компактнее JVM.

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