2009-10-18

Интеграция на уровне вызовов или мета-данных?

Архитектура ИС на основе Web-сервисов позиционируется как поддерживающая динамическое связывание с помощью мета-языков WSDL, UDDI и SSDL, а так же принципы CRUD/REST, однако, это распространенное мнение обманчиво, о чем писал еще в 2002 году Густаво Алонсо в статье "Мифы про веб-сервисы" (Gustavo Alonso - Myths around Web Services). К сожалению, сейчас все материалы, на английском языке по этому вопросу в интернете ведут на битые ссылки, а кое-какие даже на страницу 404 на сайте Microsoft Research (о причинах остается догадываться... а для того, чтобы привести тут ссылку, мне пришлось достать копию статьи из своего бекапа и разместить у себя на сервере). Не буду повторять тут пять основных критических тезисов Алонсо, но постараюсь рассмотреть саму теоретическую возможность динамического связывания в разных архитектурах, безотносительно конкретных реализаций, проприетарных технологий и торговыхмарок.


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


CRUD/REST"интерфейсом сверху" пытается решить ту же проблему, ограничивая модуль не только , но и "нижним интерфейсом", более того, оба этих интерфейса становятся идентичными между собой и одинаковыми для всех систем. Ограниченный набор команд не решает проблему связывания, он просто смещает ее с уровня вызовов к уровню мета-данных. Действительно, связывание на уровне вызовов предельно простое, например, в HTTP протоколе набор команд сводится к GET, POST, PUT, PATCH, DELETE, LINK, UNLINK, HEAD, OPTIONS, TRACE, CONNECT. Параметры этих команд так же формализованы и фиксированы. Но принципиальная проблема в том, что логика одного модуля ничего не "знает" о логике другого, кроме того алгоритма, который "зашил" программист. Как же может произойти динамическое связывание, если новая функциональность остается невостребованной, а старую, тем временем, приходится поддерживать. Сформулируем задачу яснее: как две системы, имеющие разные языки, разную логику и разную лексику, т.е. просто - разную информационную модель могут договориться? Ответ очевиден: без установления правил отображения информационных моделей двух систем друг в друга, динамическое связывание просто не имеет смысла. А когда таких информационных систем не две, а больше? А нам интересен именно общий случай автоматизации межсистемной интеграции. Гораздо проще решить проблему введя во все системы одну информационную модель, тогда мы получаем выигрыш в количестве правил отображения: вместо (N2-N)/2 нам нужно будет всего N двухсторонних конвертеров. Но все интегрируемые системы должны иметь разные модели, т.к. решают разные задачи и даже одни и те же объекты и явления описывают с разных сторон, классифицируют и формализуют иначе.


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

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

2009-10-16

Литература 2

Еще хочу порекомендовать:

1. Д. Тапскотт "Электронно-цифровое общество" (Don Tapscott "The digital economy") 1999. На каждой странице этой книги Вы найдете десяток готовых идей для бизнеса.
2. У. Эшби "Введение в кибернетику" (William Ross Ashby Introduction to Cybernetics) 1962. Классическое произведение по самоорганизующимся системам.
3. Ибн ал-Араби. "Геммы мудрости" и другие работы, особенно что касается теории единства бытия, даже если Вам кажется, что это от информационных систем далеко, но в то время и в тех местах любая наука была богословской дисциплиной, поэтому и лексика и абстракции у ал-Араби такие, что предварительно нужно изучить Торру, Книги пророков, Новый завет, Коран.
4. Н. Винер "Кибернетика, или Управление и связь в животном и машине" (Norbert Wiener "Cybernetics: Or Control and Communication in the Animal and the Machine") 1948. Замечательная книга, которую просто обязан прочитать каждый ИТ архитектор, тут даже комментировать нечего, лучше автора не скажешь.

2009-10-15

Конец индустриального века

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

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

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

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

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

Каковы же должны быть эти мета-технологии, позволяющие сделать описанную схему реальностью? Вот ключевые особенности:
1. Использование онлайновых "мастеров" для персональной компоновки заказа
2. Автоматизированное планирование технологических процессов и поставки сырья
3. Динамическое связывание производственных мощностей с минимизацией затрат
4. Исчезновение торговых площадок и переход к доставке готового товара непосредственно в место потребления
5. Отслеживание перемещения сырья, товаров, контейнеров, средств производства и транспорта с помощью систем GPS и чипов радиочастотной идентификации RFID
6. Контроль качества и сервисное сопровождение товаров на протяжении всего цикла: (заказ, производство, поставка, использование, обслуживание и утилизация) что достигается благодаря идентификации товаров, производителей и клиентов
7. Обеспечение обратной связи от потребителей товаров и услуг, которая влияет на алгоритмы принятия решений при повторном цикле производства уже модифицированных версий товара. Ведь кто является экспертом в удобстве и улучшении эксплуатационных характеристик товаров? Конечно же - это потребитель, а значит он наиболее ценный специалист для компаний производителей.

Мораль в конце выводить не будем т.к. ожидаем продолжения...

REST и CRUD против RPC

Развитие сетевых коммуникаций началось со специализированных протоколов, заточенных под прикладные нужды и повторяющих функциональность друг друга во многих случаях. Концепция эта называется RPC (Remote Procedure Call) или вызов удаленных процедур. Характеризуется RPC тем, что функциональность приложения полностью отображена в наборе команд протокола, например: FTP, POP, NNTP, протоколы СУБД, не говоря уже про многочисленные протоколы систем промышленной автоматизации или прикладных систем. Более поздние RPC стали абстрактными, т.е. появился некий стандарт, описывающий протокол, а уже на его основе разрабатывались прикладные службы, обладающие конкретным набором команд, например: SunRPC, DCOM, CORBA, Java RMI, и т.д.

Следующий шаг заключался в ограничении набора команд до "универсального минимума" и перенесении всей смысловой нагрузки в параметры вызовов. Подход этот получил название CRUD по первым буквам команд (create, read, update and delete), а архитектура информационных систем, построенная на базе подхода - REST (Representational State Transfer). Клеинт-серверные приложения в CRUD/REST архитектуре работают ресурсом и вызовом, как основными абстракциями. Ресурс (чаще всего файл) - это ответ сервера, содержащий данные и текущее состояние. Состояние - это набор параметров ресурса, которые изменяются во времени. Запрос приводит к передаче ресурса на клиентскую сторону, где пользователь с ним работает и при следующем запросе отправляет ресурс обратно на сервер вместе с состоянием.

Таким образом, архитектура REST полностью отвергает возможность установления сессии, а следовательно не дает возможности хранения состояния на стороне сервера. В отличие от REST, сервера RPC ставят в соответствие определенную область памяти сервера с каждым подключенного пользователем, создают идентификатор сессии и устанавливают соединение: виртуальное (по идентификатору) или постоянное (не закрывая сокет между вызовами).

Преимуществом CRUD/REST архитектуры является простое масштабирование на кластеры, возможность применения облачных вычислений, простота применения для информационных, гипертекстовых и других типичных задач. Из недостатков можно привести: невозможность создания систем реального времени, избыточность трафика, отсутствие машины состояний, как необходимого средства при разработке сложных систем. Преимуществом же RPC архитектуры является отсутствие ограничений на набор команд, установление соединений и хранение состояния на сервере, в следствии чего, RPC до сих пор являются единственным средством разработки прикладных, промышленных и других сложных систем. А очевидным недостатком RPC является сложность разработки, отладки и внедрения, что естественно при большей гибкости.

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

2009-10-14

Иерархия и эгалитарность

В архитектуре систем вопрос о двух подходах, иерархическом и сетевом (с равноправными узлами), встает давно и в самых разных аспектах:
1. В задаче классификации (taxonomy) - Классификация с единым корневым элементом против классификации на основе равноправного списка.
2. В задаче моделирования данных (data modeling) - Иерархическая вложенность, подчиненность или порождение объектов против сетевой модели данных с произвольными связями.
3. В задаче взаимодействия подсистем (distributed systems) - Архитектура клиент-сервер, многоранговая иерархия против одноранговых (пиринговых или peer-to-peer) сетей.
4. В задаче управления (control theory) - Централизованное управление (с единым целеполаганем или же с единым центром управления высокого уровня и каскадной иерархией разукрупнения задач управления) против независимых систем управления отдельными технологическими процессами без единого центра.
5. В задаче организационного менеджмента (project management) - Принцип единоначалия и иерархии против соревновательного принципа и равноправной конкуренции.

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

Принцип иерархии распространен в природе везде, где речь идет о внутренней организации "гомеостата" (автономной самоорганизующейся системы, которая поддерживает свою внутреннюю структуру, функции и параметры в заданных диапазонах в течении жизни системы). Примеры приводит нам К. Леонтьев, отмечая, что в мире все системы построены иерархически, и в организме человека, растений, животных и социальные институты и планеты, звездные системы и т.д. Однако в середине IXX века он не был знаком с работами У. Эшби и Н. Вишера по кибернетике, вводящими понятие гомеостата. С другой стороны, принцип конкуренции между равноправными системами в природе так же имеет место: конкуренция за зону обитания, за ресурсы, за преобладание определенных религиозных, социальных или политических идеологий, экономическая конкуренция. Общая картина представляется мне такой, что одноранговая конкуренция не противоречит иерархии, а является для нее дуальной парой. Т.е. организация объектов или явлений в иерархию приводит к появлению конкуренции, а появление конкуренции - к организации иерархии. Оба этих дуальных понятия способствуют развитию структуры, в противовес хаосу или энтропии.

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

2009-10-13

Язык Моделирования

Моделирование подразумевает наличие формального языка для описания модели. Таким языком может выступать как графическое представление модели в виде блок-схемы или графа, так и аудио/видео сигнал цифровой или аналоговый, регулярная грамматика или же бинарный файл. Ни один язык не может быть ни полным, ни универсальным, ни самым лучшим. Язык может быть только адекватным или не адекватным для решения конкретной задачи или достижения поставленной цели. Цель языка - хранить модель или передать ее от одного модуля системы управления к другому. Конечно же, каждый модуль или слой не может "понимать" модель целиком. Более того, вычислительная техника далека от понимания семантики модели и работает на уровне той абстракции, какую может обрабатывать алгоритм программного обеспечения (представленный на активном языке). Это не значит, что цифровая обработка не в состоянии создать модель объекта, совсем наоборот, задачи автоматизации зачастую сводятся к формализации вводимых и выводимых данных, к преобразованию между представлениями на разных языках, искусственных и природных, к обработке и анализу, оцифровке, конвертации, парсингу и другим операциям, приводящим к формированию модели объектов на используемых в системе языках. Что же остается пока прерогативой человека, так это - построение языков и построение абстракций. Мое убеждение, что это не будет доступно компьютерам никогда.

2009-10-05

Модель и мета-модель

Разберемся теперь с понятиями "модель" и "мета-модель".

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

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

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

В заключении кратко приведу стратегический архитектурный подход, который считаю оправданным в смете вышеизложенного:
1. Широкое применение интерпретируемых мета-данных (скриптовых языков и формальных грамматик) в моделировании предметной области.
2. Отделение абстрактных алгоритмов от бизнес-логики. Например, модуль для работы с изображениями в формате PNG должен быть написан на компилируемом коде, а вот модуль для статистической обработки сигналов, приходящих от датчика температуры - это типичный интерпретируемый алгоритм, который лучше всего сделать частью информационной модели и погрузить в базу данных.
3. Отказ от полной формализации данных на каждом слое абстракции в информационной системе. Ведь данные могут транзитно проходить сквозь слой, чтобы быть интерпретированы на другом слое. Нужно заметить, что максимальное понимание и интерпретация данных может быть достигнута только человеком, который работает с информационной системой.

2009-10-04

Литература

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

1. Д. Цикритзис и Ф. Лоховски "Модели данных" 1982 (русскоязычное издание "Финансы и статистика" 1985). Это замечательный обзор, включающий реляционные, сетевые, фреймовые, иерархические, бинарные, семантические, инфологические модели данных в аспекте моделирования с помощью вычислительной техники.
2. Умберто Эко "Поиски совершенного языка" 2007 (оригинальное издание "La ricerca della lingua Perfetta" 1993). Эссе об истории лингвистических моделей данных, начиная от каббалистов и искателей первоязыка, создателей комбинаторных моделей и алфавитов, полиграфий и философских языков, попыток всеобщей классификации и кодификации знаний, до гипертекста и современных течений.
3. К. Дж. Дейт "Введение в системы баз данных" 2006 ("Introduction to Database Systems" 2003) Знаменитый учебник по базам данных, на котором основываются курсы во многих университетах мира.
4. Э. Кодд "A Relational Model of Data for Large Shared Data Banks" 1970 (на русском языке "Реляционная модель данных для больших совместно используемых банков данных" 1995). Статья, в которой Кодд впервые развернуто объясняет принципы реляционного подхода.
5. Г.Буч "Объектно-ориентированный анализ и проектирование" (оригинальное издание Booch, Grady  "Object-Oriented Analysis and Design with Applications" 1997). Классическая книга по объектно-ориентированному анализу и моделированию, предназначенная больше для программистов и раскрывающая на примерах принципы моделирования данных в памяти ПК, а так же процесс анализа предметной области в ходе построения моделей.

Если Вы специалист в моделировании данных, то наверняка знакомы с этими источниками, исключая, разве что книгу Эко, которую я Вам настоятельно рекомендую, а для начинающих "архитекторов данных" каждая из этих книг должна стать находкой!