Проект АН2 и технология «Вир»

Года полтора назад я познакомился с группой людей, разрабатывающих платформу интернет-объектов АН2 и написал свои соображение о использовании «Вир» для этой платформы.
Текст статьи написан тогда, выставляю как есть. Как я сейчас вспоминаю, разговор с Андреем Чесноковым об АН2 был толчком к началу «Ворчалок» и к тому, чтобы чтобы начать разработку Вир-2.

Интернет-объекты  и технология «Вир»

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

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

Беда в том, что ни одна из современных технологий программирование не обеспечивает одновременное выполнение следующего набора требований:

  • Возможность сборки программ (объектов) из набора готовых и заказных компонент, минимизируя необходимость разработки, стоимость и увеличивая надежность и предсказуемость
  • Возможность эффективной работы программы на существенно разных аппаратных платформах
  • Высокую производительность
  • Гибкость программирования и настройки

Естественно, что отсутствие такой технологии не является принципиальным препятствием для разработки АН2. С другой стороны, наличие такой технологии могло бы существенно упростить (удешевить) выход АН2 на рынок и было бы существенным аргументов в пользу АН2.

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

Собственно, исходной задачей для технологии было сборочное программирование, во многом меня вдохновляли идеи component-oriented programming and generative programming. Эти технологии обещали прорыв, но увы, остались на уровне обещаний и неосуществленных надежд.

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

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

Другим существенным примером является среда разработки «Вир», разработанная на самой себе.

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

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

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

Аналогия с разработкой электронных устройств является всего лишь аналогией, но полезной в понимании способа работы Вира. Так, Вир позволяет делать сборку на 4 уровнях, на двух нижних уровнях используется язык программирования и компилятор, верхние два уровня – сборка узлов (достаточно больших компонент) и сборка программ работают с компонентами из репозитория. Впрочем, собранный узел также помещается в репозиторий и может быть использован в другой программе или в другой части данной программы. Примеры узлов: текстовый редактор, таблица, widget.

Для сборки вышеупомянутой программы Сайткрафт-Студия использовано (примерно):
  • 600 компонентов нижнего уровня
  • 1800 компонент 2-го уровня
  • 500 узлов (компонентов 3-го уровня)
При этом около 60% использованных компонент являются компонентами общего назначения, то есть могут использовать в других программах, остальные реализуют более специфический функционал, что не препятствует их использованию в других программах в рамках той же предметной области.
Компоненты 2 и 3-го уровня близки к объектам ООП, то есть инкапсулируют код и данные с возможностью расширения функциональности. Мы можем назвать их «конструируемыми объектами».

Комбинация высокой производительности и гибкости достигается в «Вире» за счет связывания бинарных компонент гибкими (скриптовыми) связками. При этом, всегда есть возможность выбора более гибкой связи (динамической) или более производительной статической связи (прямого вызова) строящейся в процессе динамического знакомства.

Вернусь к АН2. Очевидно, что существенной частью любого Интернет-объекта является стандартная «обвязка» (идентификация, защита, протоколы и способы взаимодействия, доступы к данным), которую желательно разрабатывать достаточно универсальным образом. Остальное, и скорее всего относительно небольшая часть такого объекта – это специфическая функциональность.

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

Если вернутся к перечисленным мной в начале требованиям, то «Вир» выглядит так:

  • Есть: Возможность сборки программ из набора готовых и заказных компонент
  • Нет: Возможность эффективной работы программы на существенно разных аппаратных платформах
  • Есть: Высокую производительность (бинарные компонеты)
  • Есть: Гибкость программирования и настройки (скрипты)

Технология «Вир» должна быть доработана для использования в АН2, в первую очередь это касается поддержки мульти-платформенности. Я планирую использовать решение аналогичное тому, что используется в Google Native Client (NaCl): компоненты переводятся в промежуточное представление посредством LLVM, а дальше происходит догенерация кода на целевую платформу. В NaCl догенерация происходит на клиентском компьютере после загрузки программы, в случае АН2 догенерация может происходит в репозитории, который может включать кэш готовых бинарных компонент на все запрашиваемые платформы или на клиентском устройстве.

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

Третья – доработка среды исполнения на разных платформах, собственно, здесь тоже можно пойти по следам NaCl.

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

Вывод: На мой взгляд использования доработанной технологии «Вир» в АН2 должно дать синергетический эффект.

Естественно, что я говорю об этом на техническом уровне, не представляя организационных и финансовых аспектов АН2.

Опубликовано в

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *