BOW Model.

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



Хочу сразу разъяснить следующие термины -
BOW Model - условное наименование распределенной модели построения объектно-ориентированных приложений. Имя было взято от одноименного проекта для которого первоначально она и была разработана (Bill Of Work, American Eagle, USA). Поскольку ниже приводится описание модели, а не реализации, все нижесказанное вообще говоря не зависит от применяемых технологий. Однако для достижения совсместимости приложений их следует базировать на одинаковых низлежащих решениях (CORBA, Java RMI, COM/DCOM).
Необходимо заметить, что модель во многом повторяет архитектурное решение Enterpriza Java Beans. Это имело свои исторические причины (см. Реализация - BOW Engine.). Она не столь детально проработана, однако имеет и свои преимущества. Основное преимущество - модель не описывает конкретную систему, и значит все недостатки реализации могут быть списаны либо на несовершенство этой реализации либо на недостаточно полное описание модели. Сама по себе модель недостатков не имеет. ;-) Шутка ;-)
Не следует рассматривать BOW Model как противопосталение EJB, это в первую очередь моя попытка систематизировать мои представления о построении распределенных систем. Вполне естественно, что я постоянно ссылаюсь на EJB как на паралельную и хорошо известную модель.
Для меня лично было очень интересно ознакомиться с EJB (уже после создания BOW Engine) и проследить паралели и отличия. Конечно же, BOW Model была несколько скорректирована после этого изучения, хотя в целом осталась той самой, реализованной в BOW Project.

Итак, система обладает следующими свойствами.
  1. Многослойная (multi-tier) архитектура. Система разбита на три части - источники данных, бизнес слой и клиент. Бизнес слой так же может быть неоднородным, отдельные компоненты внутри него могут выполнять роли источников, бизнес модулей и клиентов.
  2. Распределенность. В основном применима к бизнес уровню. Отдельные бизнес-модули (сервера) могут исполняться на отдельных машинах. Для интеграции используются готовые решения для распределенных систем – CORBA, Java RMI, DCOM. Возможно построение своих решений на базе TCP/IP или других сетевых протоколов. Однако рекомендованной средой является CORBA (без комментариев).
  3. Не зависимость от языка программирования. Описание модели не подразумевает использование конкретного языка программирования.
  4. Компонентная структура рассматривается на уровне всей системы, а не отдельного исполняемого сервера. Иначе говоря вся система состоит из набора бизнес-компонент (серверов). Все они конфигурируются для совместной работы.
  5. Модель не описывает всех деталей построение клиентского кода. Хотя для облегчения програмирования рекомендуется реализовать визуальные компоненты для настроенные для работы с типом ObjCollection, описанным в системе. Это могут быть TreeView, ListView, ComboBox и любые другие.
  6. Центром модели являются два программных интерфейса - Obj и ObjCollection. Obj предназначен для работы с бизнес обектами имеющими свойство постоянства (persistency). Бизнес объекты реализуют поддержку этого интерфейса либо путем наследования от класса реализации Obj либо путем его агрегирования. ObjCollection предназначена для автоматизации управления набором объектов (коллекций). Хотя и Obj и ObjCollection предназначены в первую очередь для постоянных объектов и коллекций их можно с успехом использовать для непостоянных (non-persistent, session) объектов и динамических коллекций. Базовые классы, реализующие Obj и ObjCollection, дополнительно обеспечивают жизненый цикл объекта. Основные моменты жизни, такие как "загрузка", "сохранение", "новый экземпляр" и "удаление" сопоставляются, в зависимости от реализации, либо виртуальным функциям, либо указателями на процедуры - обработчики событий. В любом случае, базовые классы полностью реализуют необходимый механизм жизнедеятельности, но могут быть заменены кодом разработчика класса.
  7. Бизнес-интерфейс обеспечивает всю необходимую функциональность для работы с объектом, то есть работа с источником данных и бизнес-операции. Это отличается, например, от идеологии EJB, где имеется тенденция для обеспечения бизнесс-операций создавать session beans, а для операций с базой данных - entity beans. Кроме того, модель не требует от разработчика создания finder-методов. Для получения ссылки на объект можно создать специальный метод в любом классе. Однако рекомендуется для каждой аппликации создавать специальные объекты - контейнеры finder-методов, выделенные для такой работы. Такой объект может быть как session, так и persistent. Его следует рассматривать как фабрику объектов, и возможно как контейнер для глобальныз переменных. Еще раз - никаких требований и ограничений на такие объекты модель не налагает, их семантика определяется только бизнес-требованиями приложения, но никак не модели. Это опять-таки отличает модель от подхода EJB, где finder-методы используются контейнером для компиляции сопроводительного кода на основе deployment descriptor'а.
  8. Модель предусматривает наличие списка объектов (object pool) используемых в рамках одного модуля (компонента, сервера). Это позволяет избежать повторной загрузки объектов из внешних источников данных (баз данных) и увеличить производительность и согласованность системы. Список может быть реализован внутри системы или использован уже имеющийся из низлежащего решения (например из CORBA ORB).
  9. Модель рассматривает session и persistent объекты как сущности одних и тех же классов. Persistent объект ассоциирован с object ID и его состояние ассоциировано с состоянием записи (записей) в базе данных. Session объект такой ассоциации не имеет. Клиент может вызвать объект как persistent, путем указания object ID, или как session, если object ID не указан. Какой тип объекта следует применять - определяется не моделью, а бизнес логикой приложения. Однако рекомендуется разрабатывать объекты с предопределенным представлением о типе его использования. Это отличает модель от концепции EJB, где тип bean должен быть жестко определен на этапе его разработки. Persistent объект хранится в списке объектов и предназначен для совместного использования несколькими клиентами, а session объект в списке не хранится и существует только пока клиент его использует. Каждый новый запрос session объекта создает новый объеки в памяти. Session объект может иметь и может не иметь состояние. Аналог stateless session bean может быть реализован как коллекция session объектов, но это не является требованием к реализации модели и может быть сделано на уровне приложения.
  10. Интерфейс к базам данных. Для обеспечения независимости от источника данных (ODBC, JDBC, BDE, естественные интерфейсы от производителя и т.д.) используется единый интерфейс DataPortal. Для каждого конкретного источника создается свой собственный класс (wrapper) реализующий DataPortal. Obj и ObjCollection работают только с DataPortal. Как минимум, DataPortal должен быть един в рамках конкретной реализации BOW Model. Создание универсального, многоплатформенного DataPortal весьма желательно, но выходит за рамки BOW Model.
  11. Абстракция языка манипуляций с данными (DML). Obj и ObjCollection, а так же методы бизнес классов не работают напрямую с DML источника данных (например SQL). Вводится дополнительный уровень абстракции - репозиторий DML запросов (SQL Manager). Бизнес метод работает с именем DML запроса. Соответствие имени и тескста DML запроса - задача для конфигуратора системы. Таким образом достигается независимость реализации классов от синтаксиса низлежашей базы данных и от структурв данных представленной на ней. Рекомендуется обеспечить возможность автоматического генерирования несложных запросов.
  12. Менеджер ресурсов (Resource Manager) представляет из себя хранилище всех ресурсов используемых в системе. Ресурсы доступны по их условным именам. В первую очередь это DataPortal'ы. Бизнес классы не знают о параметрах ресурсов которыми они пользуются. Это задача этапа конфигурации системы. SQL Manager интегрируется в Resource Manager, таким образом DML тоже являются ресурсами и доступны через единый интерфейс менеджера ресурсов. Ресурсы могут быть блокируемые и совместного использования. Блокируемые могут быть использованы в конткретный момент времени только одним методом и должны быть освобождены после использования, типичный пример - DataPortal. Ресурсы совместного использования могут быть использованны совместно и одновременно, примером служат DML выражения.
  13. Два уровня компонентной модели. Итак, благодаря абстракции конкретного бизнес класса от деталей соединения с источником данных, синтаксиса языка манипуляций и структуры данных, мы можем рассматривать бизнесс класс как программный компонент, который может быть повторно использован в разных приложениях использующие разные исходные данные. Это первый компонентный уровень в BOW Model.
    Необходимо отметить, что бизнес классы не являются независимыми, они жестко связаны между собой в пределах адресного пространства одного исполняемого модуля (сервера) на этапе компиляции. Таким образом, более правильно называть компонентом не отдельный класс, а весь исполняемый модуль целиком. Если приложение состоит из нескольких исполняемых модулей (серверов), то его можно рассматривать как построенное из отдельных компонент, настраиваемых в одно целое. Это второй компонентный уровень BOW Model. Он в большей степени соответствует классическому определению программных компонентов.

Создано: 27 декабря 2001
Обновлено: 28 декабря 20001
Продолжение и обновление следует...