Сеть документов, сеть приложений или сеть баз данных?
Часть 1
Человеческий мозг склонен считать временное постоянным, а частные случаи ошибочно принимать за абсолютные истины. Практика использования бумажных документов настолько сильно обосновалась в сознании за многие века применения рукописных и печатных носителей информации, что автоматически была перенесена и в сферу электронных коммуникаций. Таким образом, имитация бумажных документов в цифровом виде, привела к созданию глобальной паутины гипертекстов, которая является не более, чем сетью документов со ссылками. Для поиска в этом массиве информации потребовались средства индексации - поисковые машины, которые породили целую индустрию поисковой оптимизации и контекстной рекламы. Не смотря на то, что поисковые машины выполняют каждый день в сотни раз больше запросов к электронным документам, чем существует веб-страниц во всемирной сети, найти адекватную информацию с каждым днем становится все сложнее. С ростом количества страниц и автоматическим дублированием контента скорость и качество индексации снизились.
Тем временем, возможности новых информационно-коммуникационных технологий позволяют создавать нечто большее, чем сеть документов со ссылками, а запросы на интеграцию прикладных программных систем велики. Интеграция приложений востребована как никогда в производстве, транспорте, сфере услуг, финансовых сервисах и других быстро развивающихся и высокотехнологичных отраслях. Имитация “бумаги” уже не удовлетворяет задачи интеграции приложений. Мы говорим именно про задачи интеграции, т.к. локальное (не сетевое) программное обеспечение используется уже несколько десятилетий, а сейчас остро встала проблема сетевой интеграции.
Нынешний веб постепенно переходит от статических страниц к динамическим веб-приложениям, но принципы интеграции не изменились. По сути, единственным связующим звеном между разобщенными прикладными программами остается пользователь, который осуществляет взаимодействие меду системами на уровне пользовательского интерфейса (копирование через буфер обмена, экспорт/импорт через офисные форматы данных, ручная верстка и подготовка данных, ручной ввод или сканирование, полуавтоматические расчеты в электронных таблицах).
К сети документов или сети веб-интерфейсов невозможно строить формализованные сложные запросы, необходимые для прикладных приложений, а средства синтаксического анализа и разбора страниц очень сильно зависят от разметки и стилей. Интеграция же информационных систем через средства парсинга страниц осложняется нестабильной структурой и постоянным изменением верстки, вследствие чего, распадаются слабосвязанные приложения, интегрированные на уровне пользовательских интерфейсов.
Развитие прикладного программного обеспечения пошло иным путем, чем гипертекстовые страницы и веб-приложения. Для прикладного ПО, представленных, зачастую клиент-серверной архитектурой и ограниченного масштабами офиса (а в лучшем случае компании или внутренней информационной сети предприятия), характерно применение оконных пользовательских интерфейсов с одной стороны и специализированных сетевых протоколов, с другой. Тут интеграция ведется не только на уровне интерфейса пользователя, наоборот, этого стараются избегать. Основное средство интеграции систем прикладного ПО – это сетевые API и удаленный вызов процедур. Однако, проблем в этой сфере не меньше. Частые изменения бизнес-модели в производстве и услугах приводят к изменению структур баз данных и, следовательно, к изменению API интерфейсов, как внутри систем, так и внешних интерфейсов интеграции. Таким образом, каждое изменение в данных приводит к цепной реакции через слой данных, слой приложений и вплоть до изменений в слое пользовательского интерфейса. Все эти изменения очень сложно автоматизировать и зачастую они ложатся на плечи разработчиков, которые исправляют все три слоя систем в ручном или полуавтоматическом режиме. Подход этот связан с задержкой во времени и медленной реакцией прикладного программного инструментария на запросы рынка. Кроме того, стоимость разработки и поддержки такого прикладного ПО велика, а годовая стоимость владения и непрямые затраты на администрирование, масштабирование, интеграцию, синхронизацию и портирование подобных систем, часто даже превышают расходы на их создание.
Как компромисс между тяжеловесным и дорогим прикладным ПО и дешевыми и быстроизменяющимся веб-приложениями, появились так называемые веб-сервисы. Это сетевые API, работающие на базе HTTP протокола и других открытых стандартов, как XML или JSON. Стоимость интеграции межкорпоративных систем на базе веб-сервисов действительно ниже, т.к. не нужно изобретать специализированных протоколов, а библиотеки поддержки самых распространенных форматов доступны для любого языка. Но цепная реакция при изменении структуры данных для веб-сервисов также актуальна. В общем, два описанных выше подхода можно назвать сетью приложений, что является другим крайним заблуждением, основанном на ложном принятии подвижной и постоянно меняющейся предметной области за фиксированный и неизменный во времени монолит.
А что же дает нам интеграция на уровне данных? Действительно, приложения, использующие в качестве хранилища общую базу данных, как бы интегрированы автоматически, конечно при условии грамотного планирования базы данных и введения уровня хранимых процедур, не позволяющих приложениям вносить в базу некорректные, неполные или противоречивые данные. Это возможно только для закрытых корпоративных систем, потому, как открывать доступ к внутренним базам данных для внешних приложений – недопустимо по соображениям безопасности. Есть и другие причины, ограничивающие данный подход: доступ приложений к базам данных через каналы связи общего пользования затруднен, т.к. между сервером приложений и СУБД нужно иметь быстрый канал связи (по ширине и скорости отклика). Кроме того, хранить все в одной базе невозможно даже в масштабах предприятия, не говоря уже о межкорпортативном взаимодействии и интеграции. Системы, интегрированные на уровне данных, хорошо стыкуются на этапе проектирования, но на этапе использования, любое изменение в структуре данных приводит к той же цепной реакции и переписыванию логики на уровне сервера приложений и на уровне клиентского интерфейса.
Итак, интеграция на уровне данных используется, почти исключительно в закрытых системах и внутренних сетях предприятий, а задачи интеграции, хотя и решаются проще, но ограничены более узкой сферой применения. Такие информационные системы можем назвать сетями баз данных. Имеем три подхода: сети документов, сети приложений и сети баз данных, каждый из которых создавался без учета необходимости глобальной межсистемной интеграции приложений и вывода задач интеграции в сети общего пользования, как интернет, мобильная связь и другие беспроводные коммуникации.
Глубже проанализировав ситуацию с интеграцией прикладного ПО, можно заметить, что и пользовательский интерфейс и приложения и базы данных, являются только отображением модели предметной области. Сейчас модель предметной области для программного обеспечения, описывают в технических заданиях и документации к проектам, но создание электронной модели предметной области применяется крайне редко (например в продуктах, разработанных с помощью и по методологии Rational Rose). И даже в тех случаях, когда электронная модель предметной области создается, то ее использование сводится к компиляции модели в готовый программный продукт, а не к интерпретации модели в реальном времени.
Предлагаемый подход заключается в создании сети метаданных, т.е. сети моделей предметных областей, допускающих постоянную свою модификацию и интерпретацию. Таким образом, задачи построения всех трех слоев информационных систем сводятся к интерпретации мета-модели, что включает: динамическое построение пользовательских интерфейсов, динамическое построение прикладных API-интерфейсов и динамическое построение и модификацию структур баз данных.
Не уж то модификация системы будет проходить без перепрограммирования задач бизнес-логики? Конечно же нет, бизнес логика должна быть частью мета-модели и быть написана на интерпретируемом языке программирования. Более того, бизнес-логика не может быть разбита на логику базы данных, логику сервера приложений и логику клиентской части. Мы не программируем поведение программного обеспечения, создавая мета-описание объекта. Вместо этого, мы программируем логику поведения объекта на всех стадиях его жизни, т.е. один и тот же скрипт может и должен исполняться над данными во всех звеньях информационной системы, на клиенте и на сервере.
Многие практики могут справедливо возразить: “А как же скорость исполнения?“. Ведь не секрет, что интерпретируемый язык всегда медленнее, чем язык компилируемый. Ответ есть: нужно разделить бизнес-логику и абстрактные алгоритмы обработки информации (такие как, операции с матрицами, парсинг и регулярные выражения, работа с форматами данных GIF, PDF, CSV и т.д.). Библиотеки алгоритмов должны быть специально написаны не для конкретного приложения, а для класса приложений, что естественным образом предполагает повторное использование кода. Если библиотеки создаются с помощью объектно-ориентированных языков, то классы их будут отделены от классов конкретного приложения, а программист не будет смешивать логику объекта и системные задачи (что часто случается при создании приложений традиционной архитектуры). Для примера можно привести такие библиотеки: для гео-информационных систем (GIS), для сетевых приложений, для приложений финансовой аналитики, для приложений статистики, для приложений обработки изображений и т.д. Такие библиотеки будут выполнять до 90% самых ресурсоемких операций (используя процессор, память, сеть, жесткий диск и другие устройства), а скрипты бизнес-логики будут, содержать “чистый” код логики объекта, полностью отделенный от системных задач. Конечно же, компилируемые библиотеки будут исполняться быстро, а производительность интерпретируемых можно повышать, используя кеширующую прекомпиляцию, как это делается в серверах СУБД. Но таких языков как PL/SQL и Transact-SQL, естественно не хватает для написания логики приложений, и они не могут быть распространены на слой приложений и на слой пользовательских интерфейсов. Для поставленной задачи, сейчас наиболее подходит JavaScript, стандарт скриптовых языков де-факто, имеющий множество высокопроизводительных реализаций на разных платформах.
Итак, мы приходим к необходимости иметь один язык программирования для написания логики объектов и ее отработки как на сервере, так и на клиенте. При создании архитектуры, основанной на мета-моделях, мы исходим из таких допущений:
• предметная область так же изменчива, как и данные и мы не можем “зашить” одно поведение системы, не заботясь о постоянной модификации данных и логики во все время эксплуатации информационной системы;
• мы не привязываемся к аппаратной или программной платформе при реализации своего подхода, а основываем систему на открытых форматах описания объектов и интерпретируемом языке, который можно реализовать для любой платформы;
• межсистемная интеграция приложений происходит через динамическое связывание, когда данные, интерфейсы и программные вызовы формируются динамически в момент взаимодействия с пользователем или между различными системами;
• применяется принцип отображения, когда объект предметной области, т.е. модель высшего уровня абстракции, отображается сразу в три слоя низшей абстракции, а не как это происходит в традиционных системах, когда объект предметной области отображается только в один слой информационной системы (интерфейс, приложение или базу данных, соответственно одному из трех описанных выше традиционных подходов), а тот в свою очередь приводит к каскадному изменению двух других слоев;
• объект на уровне предметной области живет без декомпозиции данных и логики, и имеет среду “сквозного исполнения” и “сквозного хранения”, когда на всех этапах работы системы используется один язык для бизнес-логики и один язык для описания метаданных.
Человеческий мозг склонен считать временное постоянным, а частные случаи ошибочно принимать за абсолютные истины. Практика использования бумажных документов настолько сильно обосновалась в сознании за многие века применения рукописных и печатных носителей информации, что автоматически была перенесена и в сферу электронных коммуникаций. Таким образом, имитация бумажных документов в цифровом виде, привела к созданию глобальной паутины гипертекстов, которая является не более, чем сетью документов со ссылками. Для поиска в этом массиве информации потребовались средства индексации - поисковые машины, которые породили целую индустрию поисковой оптимизации и контекстной рекламы. Не смотря на то, что поисковые машины выполняют каждый день в сотни раз больше запросов к электронным документам, чем существует веб-страниц во всемирной сети, найти адекватную информацию с каждым днем становится все сложнее. С ростом количества страниц и автоматическим дублированием контента скорость и качество индексации снизились.
Тем временем, возможности новых информационно-коммуникационных технологий позволяют создавать нечто большее, чем сеть документов со ссылками, а запросы на интеграцию прикладных программных систем велики. Интеграция приложений востребована как никогда в производстве, транспорте, сфере услуг, финансовых сервисах и других быстро развивающихся и высокотехнологичных отраслях. Имитация “бумаги” уже не удовлетворяет задачи интеграции приложений. Мы говорим именно про задачи интеграции, т.к. локальное (не сетевое) программное обеспечение используется уже несколько десятилетий, а сейчас остро встала проблема сетевой интеграции.
Нынешний веб постепенно переходит от статических страниц к динамическим веб-приложениям, но принципы интеграции не изменились. По сути, единственным связующим звеном между разобщенными прикладными программами остается пользователь, который осуществляет взаимодействие меду системами на уровне пользовательского интерфейса (копирование через буфер обмена, экспорт/импорт через офисные форматы данных, ручная верстка и подготовка данных, ручной ввод или сканирование, полуавтоматические расчеты в электронных таблицах).
К сети документов или сети веб-интерфейсов невозможно строить формализованные сложные запросы, необходимые для прикладных приложений, а средства синтаксического анализа и разбора страниц очень сильно зависят от разметки и стилей. Интеграция же информационных систем через средства парсинга страниц осложняется нестабильной структурой и постоянным изменением верстки, вследствие чего, распадаются слабосвязанные приложения, интегрированные на уровне пользовательских интерфейсов.
Развитие прикладного программного обеспечения пошло иным путем, чем гипертекстовые страницы и веб-приложения. Для прикладного ПО, представленных, зачастую клиент-серверной архитектурой и ограниченного масштабами офиса (а в лучшем случае компании или внутренней информационной сети предприятия), характерно применение оконных пользовательских интерфейсов с одной стороны и специализированных сетевых протоколов, с другой. Тут интеграция ведется не только на уровне интерфейса пользователя, наоборот, этого стараются избегать. Основное средство интеграции систем прикладного ПО – это сетевые API и удаленный вызов процедур. Однако, проблем в этой сфере не меньше. Частые изменения бизнес-модели в производстве и услугах приводят к изменению структур баз данных и, следовательно, к изменению API интерфейсов, как внутри систем, так и внешних интерфейсов интеграции. Таким образом, каждое изменение в данных приводит к цепной реакции через слой данных, слой приложений и вплоть до изменений в слое пользовательского интерфейса. Все эти изменения очень сложно автоматизировать и зачастую они ложатся на плечи разработчиков, которые исправляют все три слоя систем в ручном или полуавтоматическом режиме. Подход этот связан с задержкой во времени и медленной реакцией прикладного программного инструментария на запросы рынка. Кроме того, стоимость разработки и поддержки такого прикладного ПО велика, а годовая стоимость владения и непрямые затраты на администрирование, масштабирование, интеграцию, синхронизацию и портирование подобных систем, часто даже превышают расходы на их создание.
Как компромисс между тяжеловесным и дорогим прикладным ПО и дешевыми и быстроизменяющимся веб-приложениями, появились так называемые веб-сервисы. Это сетевые API, работающие на базе HTTP протокола и других открытых стандартов, как XML или JSON. Стоимость интеграции межкорпоративных систем на базе веб-сервисов действительно ниже, т.к. не нужно изобретать специализированных протоколов, а библиотеки поддержки самых распространенных форматов доступны для любого языка. Но цепная реакция при изменении структуры данных для веб-сервисов также актуальна. В общем, два описанных выше подхода можно назвать сетью приложений, что является другим крайним заблуждением, основанном на ложном принятии подвижной и постоянно меняющейся предметной области за фиксированный и неизменный во времени монолит.
А что же дает нам интеграция на уровне данных? Действительно, приложения, использующие в качестве хранилища общую базу данных, как бы интегрированы автоматически, конечно при условии грамотного планирования базы данных и введения уровня хранимых процедур, не позволяющих приложениям вносить в базу некорректные, неполные или противоречивые данные. Это возможно только для закрытых корпоративных систем, потому, как открывать доступ к внутренним базам данных для внешних приложений – недопустимо по соображениям безопасности. Есть и другие причины, ограничивающие данный подход: доступ приложений к базам данных через каналы связи общего пользования затруднен, т.к. между сервером приложений и СУБД нужно иметь быстрый канал связи (по ширине и скорости отклика). Кроме того, хранить все в одной базе невозможно даже в масштабах предприятия, не говоря уже о межкорпортативном взаимодействии и интеграции. Системы, интегрированные на уровне данных, хорошо стыкуются на этапе проектирования, но на этапе использования, любое изменение в структуре данных приводит к той же цепной реакции и переписыванию логики на уровне сервера приложений и на уровне клиентского интерфейса.
Итак, интеграция на уровне данных используется, почти исключительно в закрытых системах и внутренних сетях предприятий, а задачи интеграции, хотя и решаются проще, но ограничены более узкой сферой применения. Такие информационные системы можем назвать сетями баз данных. Имеем три подхода: сети документов, сети приложений и сети баз данных, каждый из которых создавался без учета необходимости глобальной межсистемной интеграции приложений и вывода задач интеграции в сети общего пользования, как интернет, мобильная связь и другие беспроводные коммуникации.
Глубже проанализировав ситуацию с интеграцией прикладного ПО, можно заметить, что и пользовательский интерфейс и приложения и базы данных, являются только отображением модели предметной области. Сейчас модель предметной области для программного обеспечения, описывают в технических заданиях и документации к проектам, но создание электронной модели предметной области применяется крайне редко (например в продуктах, разработанных с помощью и по методологии Rational Rose). И даже в тех случаях, когда электронная модель предметной области создается, то ее использование сводится к компиляции модели в готовый программный продукт, а не к интерпретации модели в реальном времени.
Предлагаемый подход заключается в создании сети метаданных, т.е. сети моделей предметных областей, допускающих постоянную свою модификацию и интерпретацию. Таким образом, задачи построения всех трех слоев информационных систем сводятся к интерпретации мета-модели, что включает: динамическое построение пользовательских интерфейсов, динамическое построение прикладных API-интерфейсов и динамическое построение и модификацию структур баз данных.
Не уж то модификация системы будет проходить без перепрограммирования задач бизнес-логики? Конечно же нет, бизнес логика должна быть частью мета-модели и быть написана на интерпретируемом языке программирования. Более того, бизнес-логика не может быть разбита на логику базы данных, логику сервера приложений и логику клиентской части. Мы не программируем поведение программного обеспечения, создавая мета-описание объекта. Вместо этого, мы программируем логику поведения объекта на всех стадиях его жизни, т.е. один и тот же скрипт может и должен исполняться над данными во всех звеньях информационной системы, на клиенте и на сервере.
Многие практики могут справедливо возразить: “А как же скорость исполнения?“. Ведь не секрет, что интерпретируемый язык всегда медленнее, чем язык компилируемый. Ответ есть: нужно разделить бизнес-логику и абстрактные алгоритмы обработки информации (такие как, операции с матрицами, парсинг и регулярные выражения, работа с форматами данных GIF, PDF, CSV и т.д.). Библиотеки алгоритмов должны быть специально написаны не для конкретного приложения, а для класса приложений, что естественным образом предполагает повторное использование кода. Если библиотеки создаются с помощью объектно-ориентированных языков, то классы их будут отделены от классов конкретного приложения, а программист не будет смешивать логику объекта и системные задачи (что часто случается при создании приложений традиционной архитектуры). Для примера можно привести такие библиотеки: для гео-информационных систем (GIS), для сетевых приложений, для приложений финансовой аналитики, для приложений статистики, для приложений обработки изображений и т.д. Такие библиотеки будут выполнять до 90% самых ресурсоемких операций (используя процессор, память, сеть, жесткий диск и другие устройства), а скрипты бизнес-логики будут, содержать “чистый” код логики объекта, полностью отделенный от системных задач. Конечно же, компилируемые библиотеки будут исполняться быстро, а производительность интерпретируемых можно повышать, используя кеширующую прекомпиляцию, как это делается в серверах СУБД. Но таких языков как PL/SQL и Transact-SQL, естественно не хватает для написания логики приложений, и они не могут быть распространены на слой приложений и на слой пользовательских интерфейсов. Для поставленной задачи, сейчас наиболее подходит JavaScript, стандарт скриптовых языков де-факто, имеющий множество высокопроизводительных реализаций на разных платформах.
Итак, мы приходим к необходимости иметь один язык программирования для написания логики объектов и ее отработки как на сервере, так и на клиенте. При создании архитектуры, основанной на мета-моделях, мы исходим из таких допущений:
• предметная область так же изменчива, как и данные и мы не можем “зашить” одно поведение системы, не заботясь о постоянной модификации данных и логики во все время эксплуатации информационной системы;
• мы не привязываемся к аппаратной или программной платформе при реализации своего подхода, а основываем систему на открытых форматах описания объектов и интерпретируемом языке, который можно реализовать для любой платформы;
• межсистемная интеграция приложений происходит через динамическое связывание, когда данные, интерфейсы и программные вызовы формируются динамически в момент взаимодействия с пользователем или между различными системами;
• применяется принцип отображения, когда объект предметной области, т.е. модель высшего уровня абстракции, отображается сразу в три слоя низшей абстракции, а не как это происходит в традиционных системах, когда объект предметной области отображается только в один слой информационной системы (интерфейс, приложение или базу данных, соответственно одному из трех описанных выше традиционных подходов), а тот в свою очередь приводит к каскадному изменению двух других слоев;
• объект на уровне предметной области живет без декомпозиции данных и логики, и имеет среду “сквозного исполнения” и “сквозного хранения”, когда на всех этапах работы системы используется один язык для бизнес-логики и один язык для описания метаданных.
Комментарии
Отправить комментарий