Описание проекта ERP-системы

Наша группа разработчиков спроектировала и разрабатывает ERP-систему. Проект подразумевает создание системы сравнимой по возможностям с такими системами как Axapta, 1С, Эталон. Мы исследовали возможности ведущих ERP систем, и попытались объединить в нашем проекте сильные стороны каждой из них.

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

Основной идеей нашего проекта является построение системы-конструктора как основы для построения широкого спектра корпоративных бизнес-приложений.

Ниже описана структура системы и основные технические решения, используемые в ее компонентах.

Структура системы

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

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

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

Физическая структура системы

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

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

Основные решения архитектуры и реализации ядра системы

• Виртуальная машина для кода бизнес-приложения (на сервере приложений)
• Статически типизированный объектно-ориентированный язык программирования, синтаксически идентичный C#.
• Встроенный объектный язык запросов
• Дополнительные типы данных с семантикой NULL-значения баз данных (undefinable-типы)
• Специальный синтаксис объявления типа: int#, MyObject#.
• Константа undefined, отличная от константы null.
• Встроенные арифметические и прочие операторы поддерживают семантику данных типов.  Дополнительно существует оператор defined.
• Результатом чтения любого свойства undefined-объекта будет значение undefined соответствующего undefinable-типа.
• Компиляция в байт-код и его исполнение.
• Возможность одновременного исполнения большого количества сессий за счет использования ими общих метаданных (байт-кода, и пр.). Сессия представляет собой изолированную среду исполнения байт-кода.
• Код каждой транзакции бизнес-приложения исполняется изолированно, в отдельной сессии.
• Перемещающий сборщик мусора (compacting gc), с двумя поколениями.
• Интеграция сборщика мусора с ORM исключает необходимость использования слабых ссылок при организации кэша объектов транзакции бизнес-приложения.
• Работа с данными
• Система имеет встроенный ORM.
• Система имеет объектный язык запросов.
• Возможность присвоения объектного запроса с подставленными параметрами в качестве значения переменной в коде бизнес-приложения. Эта возможность позволяет использовать один запрос в секи from другого запроса подставляя его в качестве параметра.
• Сервер приложений имеет интертранзакционный кэш со следующими возможностями:
• Данные кэшируются между транзакциями на протяжении всей работы сервера приложений.
• Экономия памяти за счет отсутствия лишних копий данных объектов в каждой из транзакций и эффективной стратегии распределения памяти используемой кэшем.
• Кэш поддерживает строгую консистентность данных в режимах read-committed и snaphot, позволяя разработчику не беспокоиться об аномалиях согласованности данных, связанных с наличием кэша.
• Для операций чтения данных выполняется правило: каждое последующее чтение данных (содержащихся в кэше или нет) возвращает данные не старее чем предыдущее чтение.
• Все вышеперечисленные свойства кэша сохраняются и при работе серверов приложений в кластере.
• Предсказание доступа к данным (prefetching).
• Основано на сборе и использовании статистики внутри транзакции с учетом контекстов исполнения предоставляемых виртуальной машиной для любой из точек исполнения байт-кода в которой происходит доступ к данным (Context Based Prefetching).
• Также постоянно ведется сбор статистики эффективности оптимизатора. Данная статистика позволяет выявить отдельные места, где автоматическая оптимизация работает неэффективно. Данная статистика используется самим оптимизатором как обратная связь, корректируя его работу.
• Программист или администратор может анализировать статистику предсказания, пользуясь специальной GUI-программой.
• Программа позволяет показывать статистику предсказания в графическом виде с обозначением тех мест, где автоматическая оптимизация работает неэффективно.
• Пользователь имеет возможность расставлять явные хинты оптимизатору в таких местах.
• Вышеперечисленные возможности вместе образуют сбалансированную систему, которая позволяет:
• Избавить разработчика от необходимости расставлять большое количество хинтов в коде бизнес-приложения.
• Дает разработчику возможность расставлять хинты только в проблемных местах, на графическом представлении статистики (а не в коде)  и всегда по актуальной статистике.
• Вырабатывает у пользователя такой стиль программирования, при котором необходимость расставлять хинты возникает редко.
• Клиентское приложение. На текущем этапе разработки планируется как графическое приложение Win32.
• Динамически строит пользовательский интерфейс на основе форм, отчетов, меню и других элементов пользовательского интерфейса, определенных в метаданных бизнес-приложения.
• Содержит кэш объектов бизнес-приложения необходимых для отображения.
• К данному кэшу не предъявляется строгих требований по консистентности данных.
• Кэш отслеживает идентичность объектов, предотвращая появление более одной копии бизнес-объекта. Данная особенность используется для синхронизации отображения одного и того же объекта двумя или более формами.
• Вся прикладная логика выполняется на сервере приложений. Клиентское приложение занимается только отображением и вводом данных пользователем.

Структура бизнес-приложения и процесс его разработки

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

Модель представляет собой исходный код бизнес-приложения в виде дерева метаобъектов бизнес-приложения (пространств имен, классов, форм, отчетов и др.). Сама модель не является бизнес-приложением и не может исполняться системой.

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

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

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

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

Средства разработки и текущее состояние проекта.

Проект разрабатывается на языке C++ и представляет собой набор dll библиотек. Для сетевого взаимодействия между компонентами системы используется технология CORBA, в реализации ACE TAO. В настоящий момент код компилируется компилятором C++ Builder 6, однако проект разрабатывается как кросс-платформенный и портирование на другие компиляторы не должно вызвать затруднений.

Приложения пользовательского интерфейса (клиент, среда разработки, административные утилиты) разрабатываются на Delphi Win32 с использованием клиентских библиотек ядра системы (C++).

Состояния компонентов ядра на текущий момент:

• Компилятор прикладного языка и виртуальная машина полностью реализованы.
• ORM
• Интертранзакционный кэш - полностью реализован.
• DSL для объявления классов персистентных объектов – реализован и встроен в компилятор прикладного языка.
• Подсистемы предсказания доступа к данным – спроектирована и частично реализована.
• Объектный язык запросов – находится в стадии проектирования.
• Модели
• Полностью реализованы серверная часть и библиотека для клиентской части.
• Реализован минимальный тестовый набор метаобъектов. Конкретный набор метаобъектов, необходимых для разработки бизнес-приложений (формы, справочники, и пр.), является предметом дальнейших исследований.
• Информационная база данных
• Полностью реализован генерации (регенерации) информационной базы данных по модели, включая обновление метаданных и структуры таблиц данных бизнес-приложения. Также реализован режим регенерации с инкрементальной компиляцией.
• Сервер приложений
• Реализован механизм запуска кластера серверов приложений для тестовых целей. Отсутствует API и административные утилиты, необходимые для конфигурирования кластера.
• Встроены необходимые глобальные подсистемы: ORM (интертранзакционный кэш, кластеризация), виртуальная машина (подгрузка и кэширование метаданных и кода).
• Реализована поддержка клиентских сессий. Пользуясь глобальными подсистемами клиентская сессия может исполнять код бизнес транзакций.
• Таким образом, реализовано все необходимое для выполнения минимального тестового бизнес-приложения (тестовых транзакций написанных на прикладном языке при помощи соответствующего тестового набора метаобъектов модели).
• В настоящий момент приложения пользовательского интерфейса отсутствуют. Имеется одно тестовое приложение, позволяющее создавать и редактировать модели, создавать и регенерировать информационные базы данных и запускать тестовые бизнес-транзакции.