Датацентрические системы

Датацентрические системы

Труды V Международной конференции "Проблемы управления и моделирования в сложных системах". Самара 2003.

А.И. Пацкин

РосНИИ Искусственного интеллекта, Москва

aleksandr@tochka.ru

Введение.

Некоторые перемены в науке и в технологии связаны с фундаментальным изменением мировоззрения человечества в целом. В средние века таким переломным моментом был переход в одной из прикладных наук - в астрономии, от геоцентрической системы расчетов, в которой за неподвижный центр принималась земля, к более удобной гелиоцентрической системе, с центром в солнце. Этот, на первый взгляд, частный технический вопрос был, как известно, ревниво и болезненно воспринят Церковью. Почему - понять можно, вспомнив, что до того времени человек видел себя центром и смыслом мироздания. И смена точки отсчета, радикально упростив астрономические расчеты, вместе с тем разрушила не гео-, а эгоцентрическую систему восприятия человеком себя во вселенной. Сегодня нам не очень мешает жить (а кому-то верить) вращение Земли вокруг Солнца. Но тогда это было сильнейшим потрясением основ.

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

На самом деле, все кто вчера работал за столом, с бумагами, т.е. с информацией, сегодня чувствуют, что лишились своего рабочего места. Вчера еще компьютер входил среди других полезных вещей в рабочую оболочку пользователя, создавая пресловутое автоматизированное рабочее место (АРМ). Экран служил своеобразной дверцей шкафчика с информацией. Но после того как этот шкафчик всосал в себя всё существенное из рабочего окружения работника, и перевел всё это хозяйство через сети в некое виртуальное пространство, вдруг оказалось, что пользователь смотрит на ту же дверцу уже не снаружи, а как бы изнутри, то есть сам пользователь оказался внутри очень тесного шкафчика, до рамок которого сузилась индивидуальная рабочая среда. Сегодня в непосредственном владении пользователя не осталось ничего реального, кроме доступа к виртуальному миру сетей. Где-то в его глубинах существуют такие фантомы как "почтовый ящик", "рабочий стол", "личный кабинет", "тележка с покупками"... и т.д., но здесь и сейчас есть только чужой компьютер, голый стол, ни одного листка бумаги...

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

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

Критика общепринятого "юзероцентрического" подхода.

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

Это очень выпукло демонстрирует популярность таких систем визуального проектирования, как Дельфи, принцип работы которых de-facto стал индустриальным стандартом. Схема их действия в следующем. Разработчик помещает на проектируемую форму новую кнопку или другой компонент из палитры, а затем - навешивает на эту кнопку функциональность. При этом, что характерно, внутри кода, реализующего данную функциональность, необходимо обращаться к различным элементам по именам. Другими словами, и сама визуальная форма, и все её элементы с навешенной на них функциональностью имеют некоторые имена, то есть являются самодостаточными сущностями. Элемент формы при рождении получает имя, свойства и "прописку" на форме, но изначально не связан ни с какими структурами данных внутри сети. Это значит, что при такой методике разработки центральным узлом системы является сам пользователь. Такие системы можно назвать "юзероцентрическими".

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

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

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

1 Пользователь обходится без информационной системы, что является не шуточной, а вполне реальной альтернативой;
1-2 используется некий набор документов или как множество файлов Ворда, или, возможно, в виде статического сайта, в интрасети или в интернете. Назовем это условно - уровень MS-Word.
1-3 Часть документов приобретают функциональность - уровень MS-Excell.
1-4 появляются данные непосредственно не видимые пользователю - уровень MS-Access.
1-5 Система превращается в слоноподобного монстра с использованием СУБД - уровень Oracle.

Я полагаю, что многие (если не большинство) из прошедших все эти пять стадий роста со стороны заказчика сожалеют, что не остановились на второй или даже на первой. (Разработчики обычно довольны). Для средней корпорации, решившейся на построение такой информационной системы (а у малой не найдется несколько лишних десятков тысяч), самые сжатые сроки на такое дело: один - два года. За это время успевает морально устареть большая часть софтверных и хардверных решений, заложенных в основу системы. Со стороны персонала, привыкшего как-то обходиться за эти годы, и опасающегося увольнений, встречается глухое сопротивление внедрению новации. В результате чаще всего оказывается, что средства и время потрачены впустую.

В этой ситуации некого винить, кроме собственного непонимания того, что нельзя после смены технологических эпох проектировать системы по старинке, в частности - начиная разработку от пользователя.

Помимо всего прочего, изменился сам пользователь. Пользователь тех времен обычно не видел компьютера нигде кроме работы, он разбирался в работе нескольких экранных форм или всего нескольких программ. Встретив нештатную ситуацию, он зачастую впадал в гипнотический транс, мог часами размышлять над предложением компьютера - нажать отсутствующий на клавиатуре AnyKey и т.д. Сегодня от пользователя вполне естественно ожидать навыков веб-сёрфера, машинально «кликающего» мышкой на всё на экране, что отдаленно напоминает на ссылку. То есть кликанье по ссылкам для него проходит на уровне подсознания, как фокусировка зрения. Если у него есть навык между яркими, мозолящими глаза, рекламными баннерами отыскивать нужные ссылки, и есть навык заполнения различных форм в интернете, например, делая покупки, и если такие пользователи становятся типичными, то ситуация с разработкой интерфейса кардинально меняется. Для нового поколения пользователей в их профессиональной деятельности бессмысленно особо тщательное выстраивание экранных форм с чистого листа. Новые пользователи не tabula rasa, для них интернет уже выработал определенный стиль и стандарты. Торговые сайты, стараясь выделиться, может оригинальничать в стиле, но офисное приложению лучше воспользоваться неким усредненным казенным стилем для мгновенного узнавания новыми поколениями пользователей.

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

Между тем, системы, языки и более широко - парадигмы программирования, нанизанные сегодня на ось пользователь/интернет/приложение/СУБД, имеют очень древнее происхождение и ориентацию на совершенно иную среду. Это привело к тому, что между пользователем и объектом данных, хранимым в сети, находятся несколько разнородных посредников, т.е. несколько операционных сред со своей структурой, идеологией и порядками. Рассмотрим типичную такую цепочку, между пользователем и данными.

На странице пользователя (клиента) хозяйничает JavaScript, язык алгольного типа, обращающийся вместо входа/выхода к объектам самой страницы в основном по их именам, при этом сама страница имеет структуру языка HTML.
Следующее звено цепи, считая от пользователя, это протокол HTTP, ответственный за передачу данных между клиентом и сервером. Этот посредник не создает много проблем, и вроде бы достаточно прозрачен, чтобы его не считать, но это весьма узкий и неустойчивый/ненадежный канал, требующий преобразований на входе и выходе, поэтому всё-таки с наличием этой промежуточной среды приходится считаться.
Далее на сервере ту же страницу обрабатывает или прямо генерирует несколько альтернативных технологий. Это могут быть или какие-нибудь серверные включения - Server Side Includes (SSI) например, в форме ASP (на базе того же JavaScript или VBScript) или PHP (одноименный язык программирования). Другой вариант прямая генерация страницы на основе протокола CGI - тут типичны решения на основе языков PERL или C/C++. Все перечисленные языки - классического алгольного происхождения, но вместо операций ввода/вывода используются операции с объектами.
Далее чтобы обратиться к данным из любого из перечисленных языков, обычно используется какой-нибудь объектный интерфейс, например ADO, OLE DB или ODBC.
Языком собственно запроса к СУБД обычно является SQL. Вариант SQL может использоваться для описания структуры данных.
И, наконец, в самой среде СУБД может использоваться своя язык программирования, в частности для триггеров, т.е. обработчиков событий. Так, например, в системе Oracle используется PL/SQL.

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

Несколько языков, представляющих разные звенья этой цепи (JavaScript, Perl, C, PL/SQL, Java ...) являются "классическими" императивными языками, в которых порядок действий задается последовательностью операторов, перекидывающих информацию из переменной в переменную или из объекта в объект. Эти языки генетически происходят из парадигмы полного и монопольного контроля над виртуальным процессором. Эти языки органически не приспособлены для роли "прослоек". Каждый из этих языков - своего рода "генерал", которого принуждают исполнять роль рядового/порученца, да еще - в компании других таких же "генералов", да еще - не назначив среди них главного.
Ситуация усугубляется наличием декларативных технологических звеньев (HTML, SQL ...) вперемежку с императивными звеньями.
Использование парадигмы управления событиями окончательно всё запутывают и для разработчика, и для пользователя, так как события эти происходят в трех-четырех разных местах: на странице броузера, на веб-сервере, на сервере приложений и на сервере СУБД.
Использование объектной идеологии не спасает, так как объекты существуют только в виде программистских фантомов и могут присутствовать где угодно, на станице клиента, на серверах, то есть - на всех промежуточных звеньях кроме базисного уровня СУБД, если база данных организована по реляционному принципу, как это сейчас принято практически повсеместно.

Таким образом, общепринятая ныне последовательность разработки "со стороны пользователя" неизбежно приводит к тому, что никакой стабильной и регулярной объектной среды для пользователя сегодня практически не существует. Если конкретная страница, конкретная экранная форма как-то визуально структурируется на "объекты", или если сами страницы и/или ссылки на них иногда можно воспринимать как "объекты", то этим всё и ограничивается и никаких других объектов для пользователя не существует. И, подчеркнем, нет даже потенциальной возможности постепенного выстраивания никакой стабильной пользовательской объектной среды, без фундаментального переворота современного подхода к разработке софта. Суть этого переворота - датацентризм , который кратко можно сформулировать в тезисе:

Софт должен строиться не как оболочка вокруг пользователя, а как оболочка вокруг объектов данных.

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

Основные принципы датацентрического подхода.

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

Речь идет о том, чтобы объекты этой новой сети представляли в точности понятия из концептуального мира пользователя. Среди них не должно быть "инородных тел":

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

Понятно, что такая Датацентрическая Сеть должна изначально строиться как глобальная распределенная среда, в которой не было бы дублирования и соответственно - несогласованности данных. Например, информационная система предприятия в идеале не должна содержать внутри себя объекты для предприятий контрагентов, или объекты, отражающие элементы городской инфраструктуры. Желательно, чтобы к этим "внешним" для предприятия объектам, расположенным "физически" где-то вне предприятия, в городской или государственной сети, можно было бы привязывать "внутренние" объекты предприятия так же просто и таким же логическим методом, как связываются внутренние объекты друг с другом. Это не значит, что нужно ожидать окончания неких глобальных мега-проектов, для начала строительства локальных систем. Система должна уметь строиться с любой точки. Можно вспомнить, что Юникс, Интернет, Веб, эти киты современного мира ИТ начинались очень скромно и "локально" - всего-навсего был изобретен какой-то новый протокол/язык и/или связана по кабелю пара компьютеров.

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

"Классические" императивные системы программирования, (такие как, например, JavaScript, Perl, C/C++, PL/SQL, Java, и т.д.) для реализации функциональности внутри Датацентрической Сети не подходят в принципе - по своему внутреннему устройству. Поскольку активность Датацентрической Сети будет асинхронна, ни о каком управлении последовательностью команд/операторов не может быть и речи. Адекватная задаче вычислительная модель здесь может строиться на принципах управления данными или управления событиями. Кардинальным отличием этих моделей является то, что элементарный вычислительный акт происходит не по команде извне, а при наличии и готовности всех исходных предпосылок и условий.

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

Непосредственным следствием и воплощением принципа изотропности в структуре данных должна стать изтропная сетевая вычислительная модель. Предполагается, что изотропные вычисления реализует некоторая вычислительная структура, т.е. граф, каждый узел которого может производить вычисления, как только несколько дуг графа, смежных с данным узлом предоставят необходимый для старта вычислений комплект исходных данных. При этом важно, что "входящие" и "результирующие" роли дуг заранее не назначаются: одни и те же дуги в процессе вычисления могут играть как входящую, так и результирующую роли. Этот принцип должен быть доведен до примитивных операций. Например, вместо обычной функциональной операции числового сложения, которой соответствует вычислительный узел с двумя входящими дугами, поставляющими слагаемые, и с одной результирующей дугой, передающей сумму, будет изотропная операция SUM(X,Y,Z) которая, в зависимости от конъюнктуры, может работать как Z=X+Y или как X=Z-Y или как Y=Z-X. Этой операции соответствует вычислительный узел с тремя универсальными входяще-выходящими дугами, любые две из которых могут стартовать операцию.

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

От обычного Веба Датацентрическая Сеть отличается тем, что в Вебе пользователь имеет дело со страницами/документами, а здесь - только с объектами. Страница здесь является лишь средством (автоматического и стандартизованного) изображения объекта и не представляет самостоятельной сущности. А объект - в развернутом виде представляется страницей, а в свернутом виде - ссылкой, или иногда - четко ограниченной частью страницы. Единожды попав в такую сеть и не имея адресной строки, пользователь может до бесконечности бродить по ссылкам, но не попадет в обыкновенный, "страничный" интернет.

Итак, мы выдели следующие характеризующие признаки Датацентрических Систем (Датацентрических Сетей):

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

Система Представления Знаний Абриаль 2, как прообраз датацентрической системы.

В период 2000-2003 в РосНИИ Искусственного Интеллекта автором была разработана система Абриаль. [http://www.artint.ru/packin/abrial], [http://packin.narod.ru/pro] [1][4]

Система предназначалась для построения и исследования сложных сетевых баз знаний, с нетрадиционной системой программирования и оригинальной системой навигации. На платформе Абриаля были реализованы две лексикографических базы данных [5], два Гиперсловаря: для английского языка -Тезаурус Роже [2] и для русского языка - Словарь Зализняка [3] + самостоятельно проведенная морфологическая сегментация. Технологически Абриаль был реализован в двух вариантах: в виде обычной Windows-программы и в виде CGI-скрипта, работающего на Веб сервере и позволяющего просматривать базы данных Абриаля из Сети через обычный броузер.

В момент написания данного текста, готовится к публикации 2-я версия системы. В ней, помимо множества других доработок, введены два основных новшества: 1) Конструктор баз данных, значительно упростивший разработку структуры новых сетей для пользователя; и 2) Система и язык автоматической генерации гипертекстовых оболочек для объектов, представляющих данные сети в веб-стиле как для просмотра, так и для полноценного изменения.

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

Подробнее с системой, и в частности, с работой её серверного варианта, можно познакомиться на сайте института.

Заключение

А.С. Нариньяни не раз советовал мне называть эти сетевые базы данных Гиперсетью . И хотя я не согласился, услышав в этом некоторую тавтологию (строго говоря, любая сеть и так "гипер"), но всё же, мне кажется, словом HYPERNET, возможно, назовут третий этаж здания, у которого первым этажом является Интернет , а вторым - Веб (WWW). Но как бы он ни назывался, этот Гипернет , я уверен, что это будет глобальная семантическая сеть из объектов, повязанных многосторонними связями, и что эта сеть будет организована в близком соответствии с принципами, изложенными в данной статье (в данном докладе).

Литература: