В статье «Информационные технологии у Жизни и в технике» показаны причины затрудняющие и ограничивающие развитие информационных технологий (ИТ). В качестве выхода из информационного хаоса и прекращения неотвратимой неизбежности бесконечных перелицовок программного обеспечения (ПО), предлагается переход от применения взаимозависимых программ, описывающих создание и согласованную обработку всех данных, к технологиям управления по данным, позаимствованным у живой природы, и представляемых массой независимых программ, создающих новые данные по мере появления необходимых для этого исходных данных. Здесь этот подход будет конкретизирован.
На практике, идеи управления по данным чисто математически формализованные в виде ориентированных графов и перемещаемых данных в виде «токенов» оказались сложно реализуемы и мало эффективны. К тому же требующими использования дорогой и энергоёмкой ассоциативной памяти. Поэтому предлагается реализация в виде «крупнозернистой» модели, где каждый модуль полностью выполняет обработку исходных (если они есть) и создание новых данных в пределах локальной базы данных (БД). Подобные же модули будут работать в других локальных БД, объединяя результаты в БД более высокого уровня. Когда отработаются все зарегистрировавшиеся источники данных, новые данные получат статус готовых. Аналогично, другие модули могут быть распределены по свободным ресурсам вычислительной сети осуществляя параллельную обработку различных данных. Итак:
Доступ к данным осуществляется по классификатору характеристик метаданных. Метаданные служат для указания потенциального существования и обеспечения выбора существующих данных соответственно их смысловому значению. Для создания новых данных (документов), пользователю достаточно описать их в метаданных, указав параметры и условия (ситуации, параметры обстановки, периодичность и пр.) для их получения (выборки) из ранее описанных данных (см. также статью «Информационные технологии у Жизни и в технике»). При отсутствии данных в локальной БД, запрос пересылается в БД более высокого уровня, и т.д. А уже из неё запрос будет растиражирован по подведомственным локальным БД. Результаты его отработки тоже будут интегрированы в той БД, а затем высланы в локальную БД, инициировавшую запрос, либо выше по иерархии, если запрос пришёл сверху. Таким образом, знать электронные адреса всех источников и получателей нет необходимости. Для каждой локальной БД достаточно знать только адрес более высокой по иерархии БД. Этот принцип организации транзакций позволяет осуществить легко масштабируемую и расширяемую систему.
Наиболее просто и наглядно процесс вычисления можно отобразить с помощью блок-схем. В них показано, какие данные поступают на вход каждого программного модуля, и куда передаются вычисленные в нём выходные данные. Разработан язык DFCS программирования параллельных вычислений в системе управляемой потоками данных, на котором можно описать все связи блок-схем.
В примере на блок-схеме ниже в цветных параллелограммах (больших и маленьких) указаны данные, а в белых блоках - программные модули с алгоритмами обработки данных. Пунктирными линиями обозначены действия выполняемые электромеханическими устройствами.
В блок-схеме точно определено, какие модули с какими связаны, и не нужно ассоциативной памяти, но некоторые меры синхронизации данных должны быть предусмотрены, особенно если применяется он-лайн распараллеливание «узкого» участка ветви алгоритма. Программные модули (ПМ) в некоем оптимальном сочетании загружаются в вычислительный блок (ВБ). Данные от ПМ к ПМ передаются через порты, которые могут быть представлены виртуально или регистрами физических устройств. При управлении по данным модуль, устройство или файл функционально совпадают и взаимозаменяемы. Физические порты используются для обмена данными между ВБ по каналам передачи данных и, возможно, также между ПМ в одном ВБ. Данные временно хранятся только в портах (регистрах) и иногда, возможно, в некоторой очереди. А основные массивы данных должны храниться в БД, которые должны быть выполнены как отдельные специализированные устройства, поскольку интерфейс доступа к данным должен быть одинаков – независимо от структуры и связей конкретных данных.
Данные между устройствами передаются по шине данных вдоль которой может размещаться множество пользующихся ею устройств и модулей. Перед тем как приступить к обмену данными, обменивающиеся устройства должны «захватить» шину, чтобы потом никто не вмешивался. Захват обычно происходит по алгоритму взвешивания адресов устройств на шине и занимает как минимум столько тактов, какова разрядность их адресов.
Однако существует и даже была реализована в «железе» технология захвата шины за 1 - 2 такта устройствами независимо от их числа. Учитывая прогресс технологий, можно для обмена использовать десятки или сотни шин данных, выбирая свободную. Архитектура вычислительного комплекса показана на рисунке ниже. Комплексы могут объединяться в сеть соединением их шин через адаптеры передачи данных.
Управляет работой модулей не операционная система (ОС), а протокол движения данных (ПДД) совместно с транспортной программой. Управляющая программа ПДД весьма компактна и размещается в каждом вычислительном блоке.
Именно программа ПДД запускает работу модуля, если входные данные есть. Полученное выходное данное помещается в выходной порт, откуда транспортная программа переносит его по шине данных во входной порт связанного с первым следующего модуля, а уже там своя программа ПДД запускает его в работу. Если же модули находятся в одном вычислительном блоке, то транспортная программа не используется и т.п. Если модуль отработал, а нового входного данного нет, то ПДД останавливает исполнение этого модуля. Работа модуля возобновится, когда в порту появится данное. Однако, столь, казалось бы очевидные, правила ПДД на практике не способны обеспечить устойчивую работу системы Dataflow. Возможно, проблемы с обеспечением устойчивости тоже сыграли роль в отказе от развития этой технологии. Так что «правильные» алгоритмы ПДД гораздо интереснее, и, имею основания думать, реализуемы.
Именно благодаря ПДД система управляемая по данным является принципиально децентрализованной. ОС не нужна совсем, даже для управления ресурсами. Все подобные запросы выполняются обращением к сервисам через их порты помещением в них данных с требованиями. Если ресурсов нет (заняты), то ответ не придёт и придётся подождать, возможно с выходом через порт таймаута. Ввиду полной децентрализации всех устройств и функций вычислительного комплекса, он легко масштабируется, а комплекты блоков задач можно подгружать и дублировать по мере необходимости и наличия свободных ресурсов. В принципе, система сама может распараллеливать и подгружать блоки перед которыми создаётся очередь данных. При удачном распределении модулей по автономным вычислительным ресурсам вычислительной сети, может быть реализован конвейер вычислений, когда результат (для прошлых данных) на выходе получается одновременно с получением очередной порции (новых) исходных данных.
Итак, какие шаги надо предпринять, чтобы внедрить прогрессивные ИТ?
- Разработать единую унифицированную структуру баз данных, пригодную для хранения любых данных в их взаимосвязи, включая описания метаданных. Благодаря им все "БД" в хранилище имеют одинаковую конфигурацию, не зависящую от конкретного содержания и связей хранимых данных.
В принципе, это сделано, но нигде не опубликовано. (хотя опробовано: см. статью «Информационные технологии у Жизни и в технике») - Разработать систему иерархической организации БД и технологию транзакций (вверх и вниз) на основе метаданных, для исключения конкретной адресации к источникам и потребителям данных.
- Разработать и, наконец, внедрить где-нибудь имитацию технологии Dataflow в рамках существующих Web-технологий на Web-серверах используя модель БД унифицированной структуры.
- Разработать эффективный и надёжный алгоритм протокола движения данных (ПДД).
В принципе, это выполнено, но нигде не опубликовано. - Разработать язык программирования параллельных вычислений в системе управляемой потоками данных, и компилятор для него.
Описание языка DFCS опубликовано. . Создание компилятора не представляет проблемы. - Разработать и начать производить хранилища баз данных с унифицированным интерфейсом согласно п.1, как отдельные электронные устройства.
- Разработать систему создания библиотечных программных модулей хранимых в БД программного обеспечения в хранилищах данных, систему доступа к ним через метаданные и загрузки в вычислительные блоки.
- Заменить файловую систему хранилищем БД .
- Начать производить мультипроцессорные системы с мультишинными магистралями данных и массивами электронных портов обмена данными.
А это уже давно не проблема.
Ясно, что используя имитацию Dataflow в существующих технологиях Web (см. п.3), автоматизированную систему управления технологическими процессами (АСУТП) построить нельзя. Для этого необходимо реализовать Dataflow «в железе», чем и занимались, вплоть до «перестройки», в одном из НИИ АН СССР с целью использования в мультипроцессорных контроллерах.
Но можно легко реализовать все возможности по созданию систем управления предприятием, развития независимых социальных сетей и для управления бизнес-процессами.
Полагаю, в первую очередь следовало бы выполнить п.1, тем более, что решение определённо существует, а затем пп.2 и 3, которые могут быть решены средствами стандартных Web-технологий. Этого будет уже достаточно, чтобы каждый мог самостоятельно создать полноценную систему управления, учёта ресурсов, продукции и клиентуры распределённого предприятия. Практически теми же средствами может быть организована и создана «социальная сеть» в рамках отдела, предприятия и, далее, везде. Но владелец своего узла будет обладать в нём естественными «админскими» правами в части дизайна и регулирования прав доступа.
Организация делопроизводства вообще сведётся лишь к указанию вида и атрибутов документов, требующих рассмотрения на конкретном рабочем месте (роли) и заполнения некоторых атрибутов шаблона, что обеспечит их прохождение на следующие инстанции. И если пользователям придутся по вкусу новые возможности, то это могло бы стимулировать промышленные разработки вычислительных средств в технологиях Dataflow.
Существенная новизна этой технологии в том, что любой пользователь сможет решать почти все свои прикладные задачи без обращения к профессиональным программистам. Но это не значит, что программистам грозит безработица. Наоборот, благодаря унифицированному интерфейсу обмена данными и классификаторам метаданных, разрабатываемые ими сервисы (software as a service, обозначают SaaS) смогут получить самое широкое поле применения, а разработчики пропорциональную оплату. Нечто подобное конечно уже делается, но спецсредствами через посреднические преобразования представления данных.
Технические разработки начать, скорее всего, следует с п.4 и с производства баз данных в виде универсальных устройств, см. п.6, и, соответственно, отказаться от файловых систем. Гигабайтная память должна использоваться в интерфейсе БД (где ей и место) для размещения массивов по запросам данных. В модулях же основная память нужна лишь для команд (в режиме только чтения), а для данных потребуется лишь, допустим, несколько сотен (или тысяч) регистров (портов). Например, с прерыванием при изменении состояния. И сюда «просится» что-то типа последних разработок IBM Research, вроде бы «позволяющих производить вычисления в ячейках памяти». Плюс кэш для размещения очередей.
Язык программирования, упомянутый в п.5, может понадобиться и для программирования вычислительных блоков, используемых в хранилищах данных (см. п.6).
Язык DFCS характеризуется следующими особенностями. В каждом участке сети модулей (и внутри любого модуля) данные фигурируют только в принадлежности ко входам и выходам, называемых портами. То есть не требуется деклараций переменных и достаточно декларировать представление данных в портах модулей. Поскольку порядок исполнения модулей определяется по мере готовности данных, то нет необходимости в предписании определённой последовательности исполнения модулей – нужно лишь описать их коммутации друг с другом – всё равно в каком порядке. То есть язык оказывается декларативным. Поскольку всё сводится к инструкциям с параметрами, разбора каких-либо синтаксических конструкций не требуется. Программа в процессе "компиляции" может непосредственно загружаться в память.
Модульная структура блок-схем идеально отвечает концепции программирования "сверху вниз", а взаимодействие модулей только через порты гарантирует соблюдение принципов инкапсуляции. Кроме того, модульный принцип и естественный интерфейс по данным как нельзя лучше создают все условия для организации коллективной разработки программ.
В программной части языка DFCS предполагается использовать метки и команды перехода, что как бы противоречит принципам структурного программирования. Однако, исходя из собственного опыта программирования, могу утверждать, что программа с метками и командами перехода обычно более компактна и более понятна, чем с продублированными многократно копиями блоков и набором "флажков" ради исключения команд перехода. Аналогичного мнения придерживаются и некоторые профи.
Описание языка можно скачать с Яндекс-диска