Онтологические модели -- это про проектирование/программирование/моделирование-в-большом
Вопрос про сервисы-процессы и задачи, а также сервисы-сущности (Are Services Nouns or Verbs, http://www.zapthink.com/report.html?id=ZAPFLASH-20091014) мне напомнил про необходимость онтологического уровня рассуждений, о котором говорил Chris Partrige в своей презентации июля 2007г. "Data and process revisited: ontology driving a paradigm shift in the development of business application systems" (http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2007_07_05), но навело на другие мысли, которые я опишу тут пока несколько сумбурно.
И SOA и онтологическая интеграция данных фактически про одно и то же: как наладить взаимодействие между кучей самых разных "приложений", которые в существенной мере дублируют друг друга, а также вынуждены взаимодействовать друг с другом, хотя были разработаны исходя из самых разных организационных (не хочется писать тут "бизнес", потому как к собственно бизнесу это не имеет отношения) потребностей.
SOA развивается как дисциплина, обеспечивающая гибкость "корпоративных" информационных систем. Подход интеграции данных в САПР на базе онтологических схем -- все то же самое.
В итоге все сводится к появлению универсального моделера, который моделирует окружающий мир в необходимой для менеджеров-финансистов или инженеров полноте и укладывает его в базу данных (практика "абстракция слоя данных" -- и в САПР, и в SOA). Для того, чтобы потом получилась возможность как-то с этими данными работать, добавляется "семантика", сводящаяся к утыкиванию каждого элементарного данного в какое-то место довольно большой схемы данных и обеспечению сервисов, выполняющих над этой сложной структурой какие-то операции.
Эти схемы огромны. В ISO 15926 изначально было порядка 50тыс. сущностей. В Gellish около того. В Dassault Systemes V6 универсальный моделер MatrixOne (на котором базируются все остальные модули V6, и который связывает все эти модули между собой и предоставляет им общую для всех базу данных) предоставляет возможность сделать SOA-архитектуру (чем гордятся) с 20тыс. классов "из коробки". Поясню: вы можете программировать, но вы должны понимать, что в вашем языке программирования есть 20 тыс. зарезервированных слов, каждое из которых что-то значит. Сравните это с изучением иностранного языка плюс вспомните, что компьютер не простит двусмысленностей и неточностей -- и вы получите представление о сложности сегодняшнего программирования. Никакая computer science пока тут рядом не стояла, пока это все вотчина software engineering.
Мне кажется, что application agnostic zone из презентации Chris Partrige уже есть. Вы еще не начали программировать свое "приложение", а вам уже дадено 20тыс. понятий. Вовсе не факт, что все эти понятия из системной архитектуры, а не предметной архитектуры. Вовсе не факт, что эти 20тыс. понятий все относятся к описанию самой V6 и ее модулей. Нет, в современных САПР вы обязательно найдете upper ontology во всей ее красе, вы найдете "полную схему мира", хотя и краткую по необходимости. В каждом современном САПР есть свой CYC, только он маленький и сводится к common sense только для инжиниринга -- там нет сведений о литературе и искусстве, медицине и политике.
Перепроверимся: любое корпоративное программирование сейчас сводится к освоению каких-нибудь фреймворков с десятком тысяч классов. Конечно, в каждой конкретной задаче (как и в естественном языке) вам потребуется знать всего десяток этих классов. Но если вы не хотите все время переписывать то, что уже написано давным-давно, или вам нужно, чтобы ваши действия в системе были корректны, вам придется со всем этим хозяйством познакомиться.
Еще раз перепроверимся: ISO 15926 "из коробки" на верхнем уровне включает порядка 50тыс. классов. Предполагается, что вы работаете именно с ними, и там все основное и необходимое есть. Не предполагается, что вы заново создаете все понятия по мере того, как в них возникает потребность.
Есть и другое измерение этой проблемы: софт состоит сейчас из независимых кусков (можем назвать их сервисами -- даже не связывая это с SOA. Кто-то что-то где-то для нас делает, это сервис. Это совсем необязательно "объект, выполняющий метод", ОО-подход лишь один из способов об этом думать). Программирование сегодня -- это по сути связывание таких независимых кусков-сервисов для того, чтобы создать набор сервисов более высокого уровня (даже не "приложение", как об этом регулярно напоминает Алан Кей -- см., например, тред http://ailev.livejournal.com/699111.html?thread=6148327#t6148327).
Тем не менее, забудь о рефакторинге, всяк сюда входящий: внутрь кирпичей не смотрят, это и достоинство и проблема. Я думаю, если внимательно проработать 20тыс. классов MatrixOne, а также поглядеть на все дублирующие друг друга части модулей V6 и "отрефакторить" по-человечески, то можно было бы получить систему другого класса как по масштабируемости, так и по легкости освоения и сопровождения.
Итак, современное программирование -- это работа по написанию "сервисов" над огромными плохо отрефакторенными онтологиями. Уже нет "данных", есть онтологии, но работа с онтологиями по существу отстает от работы с агентской ("выполнителями", "процессорами", "модулями", сервисами, объектами-с-методами и т.д.) частью. Рост же компьютерной мощности дает возможность плюнуть на эту онтологическую грязь, "онтологический долг" (ср. technical debt из agile).
Текущее обсуждение "программирования-в-большом" (programming-in-large, http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small) эти проблемы игнорирует, опять таки сосредотачиваясь на "языках программирования-в-большом" и тем самым сводя все изменение парадигмы к повторению истории "программирования-в-малом" для асинхронных распределенных сервисов. Мне же кажется, что акцент тут нужно делать не на том, что есть множество асинхронных распределенных сервисов, а в том, что это (включая тот факт, что сервисы эти пишутся разными людьми и отражают структуру разных предметных областей) приводит к появлению огромных слабо контролируемых онтологий и тем самым к появленю нового сорта архитектур -- "универсальных моделирующих комплексов", которые сейчас стремительно развиваются под маркой SOA.
Тем самым я рассматриваю SOA просто как способ:
-- указать на то, что подлежащие модели являются не айтишными моделями, а задающимися спецификой деятельности организации. После этого появляется эпистемологическая проблема расхождения модели и реальности, и кроме инженерной части работы возникает мыслительная часть ("полагание" онтологии) и исследовательская часть по выявлению поведения этой онтологии в реальности. Именно отсюда и родился так похожий на agile manifesto манифест SOA.
-- дать хоть какой-то набор практик жизненного цикла (software process) для программирования-в-большом. Ведь на сегодня программная инженерия говорит что-то осмысленное только про программирование-в-малом. А программирование-в-большом (которое, замечу, скрывается и внутри программирования на C++ и Java, а не только BPEL) осталось без специфичных для него практик. Вот SOA и заполняет эту брешь, уж как может.
Сама проблема "программирования в большом" для меня очень близка к тематике проектирования-конструирования. Проектирование -- это для меня полный аналог "программирования-в-большом". Ты должен собрать из (в пределе, например для ядерной подводной лодки, которую любит приводить в пример Dassault Systemes) 4 миллионов комплектующих (данных тебе в виде каталогов стандартных комплектующих главным образом, и лишь совсем чуть-чуть в виде конструируемых специально для твоего проекта особых деталей), и тем самым добиться того, чтобы эти результаты чужого труда каким-то образом заработали вместе, а вся результирующая композиция не развалилась, не взорвалась и служила долго.
Сейчас с проблемой моделирования-в-большом столкнулись модельеры, у которых встала та же самая задача modeling-in-the-large (подробнее см. megamodeling в https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/*checkout*/Publications/2009/SLE-IfMDEisSol.pdf?rev=29&root=atlantic-zoos, но эти ребята из AMMA заявили об этой проблеме на конференциях MDAFA 2003/2004, и опубликовались в 2005г. http://www.springerlink.com/content/dqj98uwqp2gbu3cx/?p=c10f5251afa74af6b134631cf4dae7a1&pi=2. У них там еще пять лет назад говорилось то, что я твержу сейчас -- "There is probably not going to be a unique monolithic modeling language (like UML 2.0) but instead an important number of small domain specific languages (DSLs) and this will only be possible if these small DSLs are well coordinated. To avoid the risk of fragmentation, we need to offer a global vision, wich can be provided by the activity of modeling in large").
Тем самым, мы наблюдаем много-много разных способов сделать language workbenches: SOA (как это ни странно), собственно language workbenches, работы типа ведущихся в группе AMMA, современные САПР с "универсальной датацентрикой" и кучерявой схемой/моделью данных/онтологией.
Это магистраль, "в большом". Это и есть текущий мейнстрим. Онтологии тут -- enabling technology.
И SOA и онтологическая интеграция данных фактически про одно и то же: как наладить взаимодействие между кучей самых разных "приложений", которые в существенной мере дублируют друг друга, а также вынуждены взаимодействовать друг с другом, хотя были разработаны исходя из самых разных организационных (не хочется писать тут "бизнес", потому как к собственно бизнесу это не имеет отношения) потребностей.
SOA развивается как дисциплина, обеспечивающая гибкость "корпоративных" информационных систем. Подход интеграции данных в САПР на базе онтологических схем -- все то же самое.
В итоге все сводится к появлению универсального моделера, который моделирует окружающий мир в необходимой для менеджеров-финансистов или инженеров полноте и укладывает его в базу данных (практика "абстракция слоя данных" -- и в САПР, и в SOA). Для того, чтобы потом получилась возможность как-то с этими данными работать, добавляется "семантика", сводящаяся к утыкиванию каждого элементарного данного в какое-то место довольно большой схемы данных и обеспечению сервисов, выполняющих над этой сложной структурой какие-то операции.
Эти схемы огромны. В ISO 15926 изначально было порядка 50тыс. сущностей. В Gellish около того. В Dassault Systemes V6 универсальный моделер MatrixOne (на котором базируются все остальные модули V6, и который связывает все эти модули между собой и предоставляет им общую для всех базу данных) предоставляет возможность сделать SOA-архитектуру (чем гордятся) с 20тыс. классов "из коробки". Поясню: вы можете программировать, но вы должны понимать, что в вашем языке программирования есть 20 тыс. зарезервированных слов, каждое из которых что-то значит. Сравните это с изучением иностранного языка плюс вспомните, что компьютер не простит двусмысленностей и неточностей -- и вы получите представление о сложности сегодняшнего программирования. Никакая computer science пока тут рядом не стояла, пока это все вотчина software engineering.
Мне кажется, что application agnostic zone из презентации Chris Partrige уже есть. Вы еще не начали программировать свое "приложение", а вам уже дадено 20тыс. понятий. Вовсе не факт, что все эти понятия из системной архитектуры, а не предметной архитектуры. Вовсе не факт, что эти 20тыс. понятий все относятся к описанию самой V6 и ее модулей. Нет, в современных САПР вы обязательно найдете upper ontology во всей ее красе, вы найдете "полную схему мира", хотя и краткую по необходимости. В каждом современном САПР есть свой CYC, только он маленький и сводится к common sense только для инжиниринга -- там нет сведений о литературе и искусстве, медицине и политике.
Перепроверимся: любое корпоративное программирование сейчас сводится к освоению каких-нибудь фреймворков с десятком тысяч классов. Конечно, в каждой конкретной задаче (как и в естественном языке) вам потребуется знать всего десяток этих классов. Но если вы не хотите все время переписывать то, что уже написано давным-давно, или вам нужно, чтобы ваши действия в системе были корректны, вам придется со всем этим хозяйством познакомиться.
Еще раз перепроверимся: ISO 15926 "из коробки" на верхнем уровне включает порядка 50тыс. классов. Предполагается, что вы работаете именно с ними, и там все основное и необходимое есть. Не предполагается, что вы заново создаете все понятия по мере того, как в них возникает потребность.
Есть и другое измерение этой проблемы: софт состоит сейчас из независимых кусков (можем назвать их сервисами -- даже не связывая это с SOA. Кто-то что-то где-то для нас делает, это сервис. Это совсем необязательно "объект, выполняющий метод", ОО-подход лишь один из способов об этом думать). Программирование сегодня -- это по сути связывание таких независимых кусков-сервисов для того, чтобы создать набор сервисов более высокого уровня (даже не "приложение", как об этом регулярно напоминает Алан Кей -- см., например, тред http://ailev.livejournal.com/699111.html?thread=6148327#t6148327).
Тем не менее, забудь о рефакторинге, всяк сюда входящий: внутрь кирпичей не смотрят, это и достоинство и проблема. Я думаю, если внимательно проработать 20тыс. классов MatrixOne, а также поглядеть на все дублирующие друг друга части модулей V6 и "отрефакторить" по-человечески, то можно было бы получить систему другого класса как по масштабируемости, так и по легкости освоения и сопровождения.
Итак, современное программирование -- это работа по написанию "сервисов" над огромными плохо отрефакторенными онтологиями. Уже нет "данных", есть онтологии, но работа с онтологиями по существу отстает от работы с агентской ("выполнителями", "процессорами", "модулями", сервисами, объектами-с-методами и т.д.) частью. Рост же компьютерной мощности дает возможность плюнуть на эту онтологическую грязь, "онтологический долг" (ср. technical debt из agile).
Текущее обсуждение "программирования-в-большом" (programming-in-large, http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small) эти проблемы игнорирует, опять таки сосредотачиваясь на "языках программирования-в-большом" и тем самым сводя все изменение парадигмы к повторению истории "программирования-в-малом" для асинхронных распределенных сервисов. Мне же кажется, что акцент тут нужно делать не на том, что есть множество асинхронных распределенных сервисов, а в том, что это (включая тот факт, что сервисы эти пишутся разными людьми и отражают структуру разных предметных областей) приводит к появлению огромных слабо контролируемых онтологий и тем самым к появленю нового сорта архитектур -- "универсальных моделирующих комплексов", которые сейчас стремительно развиваются под маркой SOA.
Тем самым я рассматриваю SOA просто как способ:
-- указать на то, что подлежащие модели являются не айтишными моделями, а задающимися спецификой деятельности организации. После этого появляется эпистемологическая проблема расхождения модели и реальности, и кроме инженерной части работы возникает мыслительная часть ("полагание" онтологии) и исследовательская часть по выявлению поведения этой онтологии в реальности. Именно отсюда и родился так похожий на agile manifesto манифест SOA.
-- дать хоть какой-то набор практик жизненного цикла (software process) для программирования-в-большом. Ведь на сегодня программная инженерия говорит что-то осмысленное только про программирование-в-малом. А программирование-в-большом (которое, замечу, скрывается и внутри программирования на C++ и Java, а не только BPEL) осталось без специфичных для него практик. Вот SOA и заполняет эту брешь, уж как может.
Сама проблема "программирования в большом" для меня очень близка к тематике проектирования-конструирования. Проектирование -- это для меня полный аналог "программирования-в-большом". Ты должен собрать из (в пределе, например для ядерной подводной лодки, которую любит приводить в пример Dassault Systemes) 4 миллионов комплектующих (данных тебе в виде каталогов стандартных комплектующих главным образом, и лишь совсем чуть-чуть в виде конструируемых специально для твоего проекта особых деталей), и тем самым добиться того, чтобы эти результаты чужого труда каким-то образом заработали вместе, а вся результирующая композиция не развалилась, не взорвалась и служила долго.
Сейчас с проблемой моделирования-в-большом столкнулись модельеры, у которых встала та же самая задача modeling-in-the-large (подробнее см. megamodeling в https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/*checkout*/Publications/2009/SLE-IfMDEisSol.pdf?rev=29&root=atlantic-zoos, но эти ребята из AMMA заявили об этой проблеме на конференциях MDAFA 2003/2004, и опубликовались в 2005г. http://www.springerlink.com/content/dqj98uwqp2gbu3cx/?p=c10f5251afa74af6b134631cf4dae7a1&pi=2. У них там еще пять лет назад говорилось то, что я твержу сейчас -- "There is probably not going to be a unique monolithic modeling language (like UML 2.0) but instead an important number of small domain specific languages (DSLs) and this will only be possible if these small DSLs are well coordinated. To avoid the risk of fragmentation, we need to offer a global vision, wich can be provided by the activity of modeling in large").
Тем самым, мы наблюдаем много-много разных способов сделать language workbenches: SOA (как это ни странно), собственно language workbenches, работы типа ведущихся в группе AMMA, современные САПР с "универсальной датацентрикой" и кучерявой схемой/моделью данных/онтологией.
Это магистраль, "в большом". Это и есть текущий мейнстрим. Онтологии тут -- enabling technology.