2010-07-08

Метамодель в задачах интеграции информационных систем

Т.Г. Шемсединов
УДК 004.9

Введение

В последнее время, в начале разработки любой прикладной информационной системы, вопрос интеграции в уже имеющуюся сложную инфраструктуру предприятия стоит острее, чем даже вопрос функционала и производительности. Интеграция стала одним из основных факторов успеха в любой сфере бизнеса, а разработка превратилась из одноразового явления в постоянный процесс, в естественное состояние системы. Стало очевидно, что информационные системы двигаются от статической модели предметной области к динамической модели, изменяющейся в реальном времени. С другой стороны, распространение сетевых средств коммуникации позволило компаниям обмениваться информацией в цифровой форме с партнерами, клиентами, подрядчиками и даже государственными органами [1,2]. В таких условиях, старые методологии разработки, архитектуры, решения и технологии реализации нуждаются в серьезной модернизации.

Постановка задачи

Задачу интеграции информационных систем можно разбить на три составляющих: интеграция внутри предприятия, межкорпоративная интеграция и интеграция в реальном времени. Если первый пункт достаточно проработан и понятен, хотя и не прост, то уже второй приводит к целому ряду проблем: гетерогенность платформ и операционных сред, различия в архитектурах ИС предприятий, различия в подходах к моделированию данных, противоречия в принципах сетевого взаимодействия, несовместимость средств визуализации и, в конце концов, отсутствие понимания между разработчиками и общепринятого подхода к интеграции, постоянные войны стандартов между ведущими ИТ-компаниями. Все это не способствует решению поставленных задач [3,4].
Второй аспект проблемы заключается в том, что разработка информационных систем обычно начинается с одного из слоев: представления, логики или данных (то есть, постановка задачи базируется на описании пользовательского интерфейса, бизнес-логики и процессов или же структуры базы данных). А ни один из слоев не описывает предметную область с достаточной полнотой, обеспечивающей динамическое связывание нескольких ИС. Дело в том, что и логика, визуальное представление и, тем более, структуры данных, в межкорпоративном взаимодействии очень динамичны и могут меняться не только в процессе проектирования и разработки информационных систем, а и во все время их ежедневной эксплуатации. Интеграция ИС на одном из уровней, и при неполном описании, приводит к тому, что изменение этого уровня в одной из систем, рушит все объединяющие связи. Поэтому, для интеграции ИС необходимо использовать описание на более высоком уровне, например, с использованием метаданных. Таким образом, мы приходим к необходимости интеграции на уровне метамоделей.

Применение метамодели

Метамодель – модель предметной области, описанная на нескольких уровнях абстракции, где каждый высший уровень полностью, целостно и непротиворечиво задает структуру данных, функциональность, отображение и связи низших уровней.
В процессе функционирования три слоя (данные, логика и визуализация) должны динамически (в реальном времени) компилироваться из метамодели предметной области (рис. 1), а интеграция нескольких ИС на уровне метамоделей приводит к отображению интегрирующих факторов на каждый слой соответственно.
Рисунок 1 – Обобщенное звено ИС, управляемое метаданными

Параметры метамодели

Какие же дополнительные параметры необходимы для описания метамодели? Обычно, при моделировании предметной области теряются очень важные параметры модели – атрибуты связей между сущностями предметной области. Дело в том, что в реляционной и объектной моделях, связи не могут иметь атрибутов. Если это необходимо, их вводят, как атрибуты сущностей, состоящих в связях, а что они в действительности принадлежат не сущностям, а связям, “знает” логика приложения, т.е. эта часть модели описывается в коде, а не в структурах данных. При интеграции же, удаленная система уже не “знает” особенностей, а семантика, описанная не полностью, просто теряется, препятствуя интеграции систем. Какие же могут быть атрибуты связей: класс связи, направление, сила связи, условия действия, время установления, стойкость и т.д. Как в реляционных СУБД, так и в языках программирования, понятие ссылки сводится к идентификации двух связываемых сущностей и не позволяет добавлять дополнительные атрибуты.
Рисунок 2 – Пример объектов, описываемых метамоделью
Теряется, так же, и целостность объектов. Реляционная и объектная декомпозиция размещает атрибуты одной сущности во многих таблицах или многих классах, однако, это приводит к тому, что обратная операция в большинстве случаев уже не возможна без человека. Часть атрибутов описаны как поля таблицы, другие же – вынесены в разные таблицы, которые ссылаются на описываемую сущность. Но связи в реляционной модели используются не только для внутреннего моделирования объектов и их сложных свойств, но и для описания внешних отношений между разными объектами. Таким образом, по связи невозможно однозначно определить, является ли дочерняя таблица частью родительской сущности или отдельной сущностью. На практике приходится даже раскрашивать ER-диаграммы и структуры баз данных, выделяя цветами группы таблиц описывающих одни сущности. Но масштабность задач требует вводить не только такую одноранговую группировку, предметная область может быть разделена на зоны, что задается как префиксы к именам таблиц или группы таблиц помещаются в разные базы данных.
Таким образом, метамодель должна обеспечивать две принципиально разных возможности: связь между объектами и включение одного объекта в другой, как составной части. Кроме того, включение объектов так же должно быть разделено на включение “сильное” (вложенный объект может существовать только внутри родительского) и включение “слабое” (вложенный объект временно находится внутри родительского контейнера).
Современные СУБД не предоставляют возможности записывать источник получения данных в полях таблиц, хотя данные могут быть взяты из импорта, введены вручную, получены из внешней системы и т.д. Приходится выходить из положения, добавляя поле, описывающее источник данных другого поля. Реляционная модель не предоставляет возможности формально указать, что одно поле является атрибутом другого поля. Задача "понимания" этой логики ложится на приложение. Чтобы упростить операции можно применять суффиксы и префиксы в именовании полей, например поле Frequency содержит значение частоты, FrequencySource – указывает на источник данных и т.д. Аналогичным образом, может храниться и время фиксации измеренной величины (например: FrequencyTime). Однако, часто может быть необходимо хранить одно или несколько предыдущих значений. Для одного значения можно добавить поле (PreviousFrequency), для хранения истории требуется введение отдельной таблицы, и вот логика уже определяется приложением, т.е. на уровне СУБД невозможно явно указать, что таблица хранит историю параметра.
Теряются, так же, точность, весомость и степень доверия к атрибутам сущностей. Сохраняя значения атрибутов, необходимо определять в метаданных, что они поступали, например, с разных датчиков из разных систем, имеющих различную погрешность. Таким образом, к полю, хранящему значение, имеет смысл прикреплять поле-спутник, для указания точности (например, максимальное возможное значения отклонения или среднеквадратическое отклонение). Сопутствующие величины так же часто теряются, например, для производственных систем, могут быть метаданные: количество проведенных изменений для получения среднего значения, хранимого в поле; доверительный интервал значения; вероятностные характеристики; которые могут изменяться в зависимости от пути поступления данных в базу; время события получения данных и т.д. Реляционные СУБД не поддерживают также операций над нечеткими величинами, их приходится хранить в нескольких полях, а обрабатывать программно. Таким образом, модель предметной области размывается между структурой базы данных, сервером приложений и клиентом, что приводит к несовместимости с другой системой.
Теряется и семантика групповых связей, когда несколько связей описывают один аспект предметной области, а инструментов для объединения связей в группы нет. Сложности есть и в формальном описании сложных свойств, когда свойство распадается на несколько полей, а описать их группировку или определить ее невозможно. В таких случаях нужно использовать метаданные, которые будут интерпретированы в сервере приложений или в клиенте.

Выводы

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

Литература

1. Дон Тапскотт. Электронно-цифровое общество. Рефл-бук, 1999, 408 с.
2. Под редакцией Н. Ермошкина. Демистификация ИТ. Что на самом деле информационные технологии дают бизнесу. 2006, Альпина Бизнес Букс, 304 с.
3. Don Tapscott. Grown Up Digital: How the Net Generation is Changing Your World. 2008.
4. Беккер Й., Вилков Л., Таратухин В., Кугелер М., Розерман М. Менеджмент процессов. М.: Эксмо, 2007. 360 с.

2010-02-17

CLEAR

Clear Language for Entity Adequate Representation

Short guide Version 7.0 Date: 2008-01-31

1. Overview

This language is designed for platform independent entity representation for memory structures, storage and network interactions as well. It is next step in data representation languages evolution after markup languages, so it is based on both, XML experience and binary data encoding. But it is devoid of indeterminacy on the one hand and is human understandable on the other hand. Clear language structures are simple and obvious so do not expect something supernatural here. It is simple and clear...

2. Requirements

  • Compact and efficient
  • Expressive and human-readable
  • High-performance parsing
  • Single-meaning syntax and modeling rules
  • Native hierarchical, table, network and relational structures support
  • Object-oriented and data types support
  • Maps directly to programming-language structures
  • Maps directly to network protocol packets
  • Maps directly to database engine structures
  • Self decrypted and extensible syntax
  • UTF-8 support
  • Security and data safety
  • Transport independent
  • BLOB support in BASE64

3. Fields

Fields are for holding named values as a entity properties. CLEAR gives possibility to defile field types using regular expressions. All characters except 0x00..0x1F, 0x25 ("%") and 0x5D ("]") are allowed in values without escaping. Escaped characters should be encoded as %NN where NN is hexadecimal character code (for example %10 or %25). Symbol 0x22 (double quotation) should be escaped only if it is the first letter in value.

Fields are of the following two formats. First is simple:

Syntax: FieldName[value]

Second format allows to use 0x5D ("]") without escaping and used for regular expressions and other values which oftenly uses square brackets: Name["value-with-]-symbol"]. But combination of 0x22 (double quotation) and 0x5D ("]") should be escaped as in example: Name["value-with-%22]-symbols"]

4. Links

Format of links is similar to fields first format except of using 0x3E (">") instead of
0x5D ("]").

Syntax: LinkName<URL>
Example: MySite<http://meta-systems.com.ua/>

5. Sets

Format of sets is similar to fields first format except of using 0x3E ("}") instead of
0x5D ("]").

Syntax: SetName{item-1,...,item-N}
Example: Colors{green,navy,yellow}

6. Entities and hierarchy

CLEAR allows organizing fields, sets and links into entities or objects. Entities are separated with line breaks (0x0D 0x0A). Objects can be organized hierarchically as trees in markup languages. Numbers in the beginning of any row are hierarchy level, for example:

1: Node1:Class1 Field1[value1] Field2[Value2] Link1<link1>
2:   SubNode1 Field3[value3] Set1{} Set2{item4,item5} Field4[value4]
2:   SubNode2 Field5[value5] Field6[value6]
3:     SubSubNode1 Set3{item6,item7} Field7[value7] Link2<link2>
2:   SubNode3 Field9[value9]
3:     SubSubNode2:Class2,Class3 Field10[value10] Link3<link3>


Thanks to level numbering we can skip branches and quickly parse to the necessary entity. It is also releases us of "end" keywords needed in other languages to close tree levels. In CLEAR, for example, level 3 object ends when next level 3 or level 2 object starts (generally when sibling or higher level object starts or EOF reached).

7. Entities Classes and Properties naming

Entity name and class definitions are precedes fields, links and sets declarations. CLEAR allows multiple for inheritance and allows entity without ancestor class at all. Classes can be defined in *.model files as type declarations. Classes separates by ":" from entity name and separates by "," from each other. For example:

1: Node1:Class1 Field1[value1] Field2[value2]
2:   SubNode1:Class2,Class3 Field3[value3]
2:   SubNode2 F[val1] F[val2] [val3] [val4] <url1>


We need to give user possibility to encode any symbol of 0x00-0xFF in entity names and class names, so 0x00-0x1F should be escaped as - %1F, also we need to escape following: colon (":") as %3A, dash ("-") as %2D, equality ("=") as %3D, plus ("+") as %2B, star ("*") as %2A, comma (",") as %2C and space as %20. So we escape only 39 chars of 256 set.

Previous example shows us fields and links without name. CLEAR allows having multiple properties (fields, links and sets) with one name or properties without name. Parser organizes those properties into arrays so we can access values by property name or array index.

8. Folders

Folders are entities used for grouping other entities. Folders have colon (":") but have no class specified. For example:

1: Folder:
2:   SubNode1 Field1[value1] Field2[value2]
2:   SubNode2 Field3[value3] Field4[value4]

9. Members

Members are complex properties of parent entities. Members have "#" as a first letter in their names. For example:

1: Node1:Class1
2:   #SubNode1 Field3[value3] Field4[value4]
2:   #SubNode2 Field5[value5] Field6[value6]

10. CLEAR model files (*.model)

Data definition files contain types and classes definitions. Model files are of common CLEAR format. See examples and explanations further at this guide.

11. CLEAR files (*.clear)

CLEAR have default extension for data files. Root entity contains links to data definition (*.model) files. For example:

1: Node1:CLEAR <http://xross.net.ua/clear.model> <models/example.model>
2:   SubNode01 Field2[value2]


12. Comments

Lines which not started with "N: " (where N is decimal number) are commented. For example:

// comments here
1: Node1:Class1 Field1[value1]
-- comments here

13. Types

In the following example you can see type definitions as regular expression and as enumerated dictionary. Type definitions marked with "Type" class and all should be at the second level of model file (directly under root node).

1: ExampleModel
2:   float:Type  ["^-?\d*\.?\d*$"]
2:   string:Type [".*"]
2:   Align:Type  {Top,Right,Bottom,Left}
2:   Class1 Aligns{Top,Left:Align} Align[Align]
2:   Class2 Field1[0:float] Field2[float]
3:     #Member Set1{0,12.5,15.1:float} Set2{string}

14. Classes

In previous example there are Class1 and Class2 declared.

2010-02-05

Сеть документов, сеть приложений или сеть баз данных?

Часть 2 (продолжение)

Очень важным вопросом в интеграции приложений есть фиксация набора стандартов. Для современного интернета характерна война стандартов, причем, концептуально одинаковых, а разных, только по реализации. Например, формальные языки описания объектов расплодились в огромном количестве, а по сути все являются различными синтаксисами одной абстракции. Абстракцию эту можно определить как “сериализация объектов”, а перечисление понятий в нее входящих, может выглядеть так: объект, свойство, значение, иерархия вложенности. Примерно такая же ситуация и с веб-сервисами, разновидностей коих мы наблюдаем великое множество, и каждый раз при создании веб-приложения разработчики стоят перед выбором из нескольких десятков конкурирующих стандартов. Какая же интеграция приложений при таком разнообразии? Большая часть процессорного времени и памяти приходятся на синтаксический разбор, конвертацию, всевозможные преобразования несогласованных форматов. Что же касается СУБД, то реляционные базы данных сейчас предоставляют действительно самую удобную и быструю инфраструктуру, доступную через семейство языков SQL. Сам структурированный язык запросов тоже очень отличается от одной реализации к другой, но хотя бы принципы закреплены и фантазия разработчиков держится в каких-то рамках, благодаря чему, интеграция приложений на уровне баз данных, конечно проще всего, но и уязвимее.

Какие же стандарты мы выберем для реализации сети баз данных, интегрированных на уровне метаданных? Исходя из чисто практических предпосылок мы вынуждены принять протокол HTTP в качестве основного транспортного средства, а веб-браузер в качестве самого распространенного клиентского терминала информационной системы. Т.е. набор инструментария для создания веб-приложений нам вполне подходит, с некоторыми оговорками, что мы закрепим кодировку UTF-8, как единственную для всех интегрированных информационных систем в этой архитектуре и примем JavaScript, в качестве скриптового языка для программирования логики объектов во всех трех слоях ИС. Что же касается межсистемного взаимодействия, нам нужно определиться с форматами описания объектов и представления метаданных. Это очень важная часть, но она заслуживает отдельной статьи, которая будет выйдет, в ближайшее время.

Какие же технические задачи мы ставим для реализации предложенной архитектуры:

1. Глобальная идентификация данных.
Для сети баз данных интегрированных на уровне метамоделей необходима единая сквозная уникальная система идентификации объектов. Т.к. мы ориентируемся на использование сетей общего назначения и интернета, то наилучшим решением будет применение URL и URI (уникальных указателя и идентификатора ресурсов соответственно). Однако, для идентификации объектов в базах данных необходимо иметь индекс в виде целого числа, а обеспечить уникальность числового индекса для межсерверной идентификации практически невозможно, да это и не нужно, ведь мы можем использовать индексы лишь для индексации внутри баз данных, они могут и не совпадать, а для идентификации связей между объектами разных баз использовать URI, состоящий из домена сервера и уникального идентификатора объекта (алфавитно-цифровой идентификатор). Такую систему глобальных идентификаторов можно назвать “развязанную через URI”.

2. Использование шаблона вместо класса.
Классический объектно-ориентированный подход использует “застывший” слепок иерархии классов, структура которого не меняется в пределах одной компиляции, а для модификации модели нужно пересобирать приложение. Реальность, все же, ближе к “подвижной” модели, когда и структура и иерархия классов используются для наследования только в момент конструирования (создания) экземпляра объекта. Это больше похоже на шаблон, который передает свою структуру “оттиску” одномоментно, а потом теряет всякую с ним связь, кроме указания имени всех шаблонов в описании экземпляра, что допускает как последующее независимое изменение структуры каждого экземпляра, без изменения класса, так и синхронизацию структуры шаблона и экземпляра. Такая реализация позволяет динамически изменять метамодель предметной области без перекомпиляции системы, а для интеграции прикладных приложений она дает необходимую гибкость структур, т.к. метамодели в разных системах могут быть различных версий.

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

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

5. Многоязычность.
Кроме нескольких версий рано или поздно возникнет необходимость иметь версии значений параметром и даже имен параметров на нескольких языках.

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

7. Система управления правами.
Вопросы владения данными и управления правами доступа, а так же процедуры безопасного обмена версиями данных должны быть реализованы с учетом распределенной сети серверов, каждый из которых может обслуживать сотни владельцев данными. Это не простой вопрос, хотя бы потому, что в общем случае пользователь “A”, обслуживаемый сервером “Б” должен иметь возможность передать права на доступ к объекту “В”, находящемуся на сервере “Г” другому пользователю – “Д” или группе пользователей, каждый из которых может находиться на разном сервере.

И наконец, кратко перечислим компоненты метамодели, которые необходимы для адекватного описания большого круга предметных областей. Круг этот можно условно ограничить как “задачи управления профилями объектов”. Итак, компоненты метамодели: профиль, параметр профиля, связь между профилями, параметры связей, группы профилей, группы параметров и группы связей.

2010-02-04

Сеть документов, сеть приложений или сеть баз данных?

Часть 1

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

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

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

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

Развитие прикладного программного обеспечения пошло иным путем, чем гипертекстовые страницы и веб-приложения. Для прикладного ПО, представленных, зачастую клиент-серверной архитектурой и ограниченного масштабами офиса (а в лучшем случае компании или внутренней информационной сети предприятия), характерно применение оконных пользовательских интерфейсов с одной стороны и специализированных сетевых протоколов, с другой. Тут интеграция ведется не только на уровне интерфейса пользователя, наоборот, этого стараются избегать. Основное средство интеграции систем прикладного ПО – это сетевые API и удаленный вызов процедур. Однако, проблем в этой сфере не меньше. Частые изменения бизнес-модели в производстве и услугах приводят к изменению структур баз данных и, следовательно, к изменению API интерфейсов, как внутри систем, так и внешних интерфейсов интеграции. Таким образом, каждое изменение в данных приводит к цепной реакции через слой данных, слой приложений и вплоть до изменений в слое пользовательского интерфейса. Все эти изменения очень сложно автоматизировать и зачастую они ложатся на плечи разработчиков, которые исправляют все три слоя систем в ручном или полуавтоматическом режиме. Подход этот связан с задержкой во времени и медленной реакцией прикладного программного инструментария на запросы рынка. Кроме того, стоимость разработки и поддержки такого прикладного ПО велика, а годовая стоимость владения и непрямые затраты на администрирование, масштабирование, интеграцию, синхронизацию и портирование подобных систем, часто даже превышают расходы на их создание.

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

А что же дает нам интеграция на уровне данных? Действительно, приложения, использующие в качестве хранилища общую базу данных, как бы интегрированы автоматически, конечно при условии грамотного планирования базы данных и введения уровня хранимых процедур, не позволяющих приложениям вносить в базу некорректные, неполные или противоречивые данные. Это возможно только для закрытых корпоративных систем, потому, как открывать доступ к внутренним базам данных для внешних приложений – недопустимо по соображениям безопасности. Есть и другие причины, ограничивающие данный подход: доступ приложений к базам данных через каналы связи общего пользования затруднен, т.к. между сервером приложений и СУБД нужно иметь быстрый канал связи (по ширине и скорости отклика). Кроме того, хранить все в одной базе невозможно даже в масштабах предприятия, не говоря уже о межкорпортативном взаимодействии и интеграции. Системы, интегрированные на уровне данных, хорошо стыкуются на этапе проектирования, но на этапе использования, любое изменение в структуре данных приводит к той же цепной реакции и переписыванию логики на уровне сервера приложений и на уровне клиентского интерфейса.

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

Глубже проанализировав ситуацию с интеграцией прикладного ПО, можно заметить, что и пользовательский интерфейс и приложения и базы данных, являются только отображением модели предметной области. Сейчас модель предметной области для программного обеспечения, описывают в технических заданиях и документации к проектам, но создание электронной модели предметной области применяется крайне редко (например в продуктах, разработанных с помощью и по методологии Rational Rose). И даже в тех случаях, когда электронная модель предметной области создается, то ее использование сводится к компиляции модели в готовый программный продукт, а не к интерпретации модели в реальном времени.

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

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

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

Итак, мы приходим к необходимости иметь один язык программирования для написания логики объектов и ее отработки как на сервере, так и на клиенте. При создании архитектуры, основанной на мета-моделях, мы исходим из таких допущений:
• предметная область так же изменчива, как и данные и мы не можем “зашить” одно поведение системы, не заботясь о постоянной модификации данных и логики во все время эксплуатации информационной системы;
• мы не привязываемся к аппаратной или программной платформе при реализации своего подхода, а основываем систему на открытых форматах описания объектов и интерпретируемом языке, который можно реализовать для любой платформы;
• межсистемная интеграция приложений происходит через динамическое связывание, когда данные, интерфейсы и программные вызовы формируются динамически в момент взаимодействия с пользователем или между различными системами;
• применяется принцип отображения, когда объект предметной области, т.е. модель высшего уровня абстракции, отображается сразу в три слоя низшей абстракции, а не как это происходит в традиционных системах, когда объект предметной области отображается только в один слой информационной системы (интерфейс, приложение или базу данных, соответственно одному из трех описанных выше традиционных подходов), а тот в свою очередь приводит к каскадному изменению двух других слоев;
• объект на уровне предметной области живет без декомпозиции данных и логики, и имеет среду “сквозного исполнения” и “сквозного хранения”, когда на всех этапах работы системы используется один язык для бизнес-логики и один язык для описания метаданных.