Специфікація каркаса інформаційної системи з розподіленою архітектурою

Євген Ігумнов

Вступ

Отриману мною специфікацію каркаса системи з розподіленою архітектурою (distributed framework - dfw) можна використовувати як відправну точку при створенні корпоративних розподілених систем. Пропонована специфікація не залежить від розподіленої технології, на основі якої буде побудована система. Іншими словами, пропонована специфікація може бути використана спільно з технологіями RMI, CORBA, DCOM та ін Проблеми реалізації інтеграції з цими технологіями не розглядаються. Вони лягають на розробників, які вирішили використовувати цю специфікацію. Специфікація була отримана при аналізі трьох типів систем: OLTP, OLAP і GIS. Каркас системи спрямований на об'єктно-орієнтована мова і в основі своїй містить набір шаблонів проектування для високого повторного використання.

1. Загальна компонентна модель

Система складається з трьох частин: клієнтська програма (GUI або Web), сервер додатків і джерело даних (СУБД, XML і т.д.). Ідеологія системи будується на трьох речах: фактах, метамоделі і безпеки. Факти-це так звані бізнес-об'єкти з предметної області, з якою буде працювати система. Метамодель - це опис цих бізнес-об'єктів. Безпека - це опис прав доступу до фактів і метамоделі. Діаграма пакетів системи зображена на рис. 1.1. Слід звернути увагу на функціональну значимість метамоделі в цій системі. Зазвичай при реалізації великої кількості типів бізнес-об'єктів (фактів) для кожного факту ставиться у відповідність клас. Для того, щоб підвищити ступінь повторного використання і спростити механізм підтримки великої кількості типів фактів у системі, слід для всіх фактів виділити всього один або два класи, а структуру фактів описати в метамоделі. Таким чином, при зміні структури фактів не потрібно буде змінювати вихідні коди, а достатньо буде поправити інформацію в джерелі даних, наприклад СУБД, звідки бере дані метамодель.

Рис. 1.1 Діаграма залежності між пакетами

Клієнтська частина складається з 10 пакетів. Пакет view відповідає за її зовнішній вигляд. Пакет mediator сполучати види програми. Пакет model відповідає за внутрішнє подання даних програми. Пакет controller містить класи, які працюють з моделлю даних програми. Пакет model.fact представляє структури фактів, якими обмінюється клієнтську програму із сервером додатків. Пакет model.meta представляє структури описують факти, тобто метамодель, якими обмінюється клієнтську програму із сервером додатків. Пакет model.security представляє структури, що описують безпеку доступу до фактів і метамоделі, якими також обмінюється клієнтську програму із сервером додатків. Пакети source.fact, source.meta і source.security відповідають за взаємодію між клієнтським додатком і сервером додатків і підтримують між ними обмін фактами (model.fact), метаданими (model.meta) і безпекою (model.security) не залежно від використовуваної розробником розподіленої технології. Іншими словами, на основі них слід робити стаб (stub) [2].

Сервер додатків складається з 9 пакетів. Пакети model.fact, model.meta, model.security такі ж, як на стороні клієнтського додатку. Вони служать value-об'єктами обміну інформацією між сервером додатків і клієнтським додатком. Пакети source.fact, source.meta і source.security на стороні сервера відповідають за взаємодія між клієнтським додатком і сервером додатків. Іншими словами, на основі них слід робити скелетон (skeleton) [2]. Пакет server.datasource відповідає за підтримку різних типів джерел даних, в яких зберігаються факти. Пакет server.factdao відповідає за взаємодію з фактами для різних типів джерел даних. Пакет server.kernel управляє функціонуванням сервера додатків, зв'язуючи воєдино всі пакети серверної частини.

В ролі джерела даних, як уже говорилося, може виступати СУБД або інше рішення для доступу та збереження даних. Швидкість роботи з джерелом природно залежить від його типу. У пакеті server.factdao швидкість можна підняти, наприклад, за рахунок стратегії кешування.

2. Концептуальна модель сервера

Сервер додатків складається з так званих заводів, які управляють об'єктами в пам'яті сервера. Заводи являють собою класи, побудовані на основі шаблонів проектування Singleton, Factory Method, Flyweight і Facade [1]. Шаблон Singleton призначений для існування всього одного об'єкта заводу в пам'яті сервера додатка, у якому містяться посилання на об'єкти, керовані ім. Шаблон Factory Method використовується для того, щоб тільки завод займався створенням об'єктів, а за шаблоном Flyweight у разі повторного запиту на такий ж об'єкт не вироблялися б витрати ресурсів сервера на повторне створення клону об'єкта, а вилучався вже готовий об'єкт з пула об'єктів. Хочу звернути увагу на те, що створення об'єктів зазвичай пов'язане з процесом зчитування інформації з таких джерел даних, як, наприклад СУБД.

В сервері додатків є три заводи. Завод MetaFactory працює з об'єктами, що представляють метамодель. Завод FactDAOFactory управляє об'єктами, які працюють з фактами. Завод SecurityFactory управляє об'єктами, що описують безпеку системи. Заводи зображені на рис. 2.1.

Рис. 2.1 Концептуальна модель сервера

Сервер програми має інтерфейси, через які з ним можна взаємодіяти. Таких інтерфейсів теж три. Інтерфейс FactSourceInterface призначений для доступу до фактами. Інтерфейс MetaSourceInterface призначений для доступу до метамоделі. Інтерфейс SecuritySourceInterface призначений для доступу до безпеки системи. При роботі з цими інтерфейсами дані загортаються в value-об'єкти, які беруться з model.fact, model.meta і model.security відповідно. Реалізують ці інтерфейси абстрактні класи AbstractFactSource, AbstractMetaSource і AbstractSecuritySource, які можна нехтувати і делегувати виклики з боку клієнтського застосування від скелетон (skeleton). Класи AbstractFactSource і AbstractMetaSource в своїй роботі використовують SecurityFactory, тому що в них інкапсульовані механізми перевірки прав доступу до фактів і метамоделі.

2.1. Пакети моделі метамоделі, фактів і безпеки

Пакет model.meta на рис. 2.2 містить класи, які описують метамодель предметної області, з якою працює система. Мною було виділено лише три основні класу для цієї мети. Безумовно, її необхідно розширювати для кожної специфічної предметної області. Клас MetaModel призначений для того, щоб тримати в одній системі декілька метамоделей. Клас FactDescription описує факти. Клас Group виступає в ролі тематичного класифікатора фактів, який завжди присутній в інформаційних системах і може бути також розширено.

Рис 2.2 Модель метамоделі

Пакет model.fact на рис. 2.3 має всього один клас Fact, об'єкти якого будуть фактами. Цей клас слід, безумовно, розширити, так як зустрінуті мною факти з різних предметних областей мають спільне лише те, що вони є фактами.

Рис. 2.3 Модель фактів

Пакет model.security на рис. 2.4 описує права доступу до системи, до фактів і метамоделі. За основу взято класичне рішення безпеки. Є користувачі (клас User), які зіставлені з ролями (клас Role), що мають права доступу (клас Access) на метамодель, яка також описує факти. Відповідно, відсутність повноважень щоб опис факту відсікає доступ на сам факт. У процесі аутентифікації бере участь клас User, а в процесі авторизації - Класи Role і Access відповідно.

Рис. 2.4 Модель безпеки

2.2. Пакет джерел даних

Пакет server.datasource на рис. 2.5 забезпечує зв'язку між джерелами даних і фактами. Іншими словами, тут описується, в якому джерелі даних знаходиться який факт. Вводиться поняття картриджа (клас FactCarttridge), що представляє джерело даних, в якому зберігаються факти. Для роботи з конкретним типом джерелом даних картридж використовує інтерфейс FactDAOInterface. Даний підхід дозволяє серверу додатків, з одного боку, зберігати свої факти в різних джерелах даних, а з іншого, не піклуватися клієнтського додатку про те, як вони зберігаються і як розташовані фізично, що полегшує клієнтську частину системи.

Рис. 2.5 Джерело даних

2.3. Пакет доступу до фактів

Пакет server.factdao на рис. 2.6 відповідає за роботу з фактами для різних типів джерел даних. За основу береться інтерфейс FactDAOInteface, що задає принципи роботи з фактами. Його необхідно реалізувати для всіх типів джерел даних, які будуть підключені до системи. При реалізації даного інтерфейсу в випадку, коли деякі джерела даних мають спільні риси, слід використовувати Template Method для збільшення ступеня повторного використання коду.

Рис. 2.6 Доступ до фактів

2.4. Пакет ядра

Пакет server.kernel на рис. 2.7 являє собою набір заводів FactDAOFactory, MetaFactory і SecurityFactory, які керують моделями пакетів model.fact, model.meta і model.security, які були описані вище. Класи AbstractMetaSource і AbstractFactSource в своїй роботі використовують безпека, тобто користуються послугами SecurityFactory. Основна функціональна навантаження ядра лягає на класи AbstractFactSource, AbstractMetaSource і AbstractSecuritySource, але процес управління об'єктами моделей model.fact, model.meta і model.security делегується класами FactDAOFactory, MetaFactory і SecurityFactory з використанням шаблону Adapter.

Рис. 2.7 Ядро системи

2.5. Пакети джерел метамоделі, фактів і безпеки

Пакет source.meta на рис. 2.8 представляє собою інтерфейс MetaSourceInterface з підтримує його заводом за шаблоном Factory Method, який надає клієнтського додатку Proxy-об'єкт цього інтерфейсу за шаблоном Proxy. Як вже говорилося вище, на стороні клієнтського додатка реалізують цей інтерфейс в вигляді стаб (stub), а на стороні сервера програми - у вигляді скелетона (skeleton).

Рис. 2.8 Джерело метамоделі

Пакет source.fact на рис. 2.9 побудований за такими ж принципами, як пакет source.meta.

Рис. 2.9 Джерело фактів

Пакет source.security на рис. 2.10 побудований за такими ж принципами, як пакет source.meta.

Рис. 2.10 Отримано безпеки

3. Концептуальна модель клієнта

Клієнтське додаток на рис. 3.1 побудовано на основі популярного шаблону Модель-Вид-Контроллер (Model-View-Controller) [1]. Моделлю служить абстрактний клас Model, який необхідно розширити для різних типів моделей, присутніх у клієнтському додатку. У ролі Виду виступає абстрактний клас View, який відповідно необхідно перевизначити для наявних видів у клієнтському додатку. У ролі контролера виступає інтерфейс Command, який необхідно реалізувати в командах, що виробляють дії над Моделлю на основі подій, що приходять у Вигляд від користувача. Також застосовується шаблон Mediator, виступаючий в ролі посередника між взаємозалежними Видами. Клієнтське додаток взаємодіє з сервером додатків через такі інтерфейси, як FactSourceInterface, MetaSourceInterface і SecuritySourceInterface.

Рис. 3.1 Концептуальна модель клієнта

3.1. Пакет вид

Пакет client.view на рис. 3.2 являє собою набір класів з посиланнями на об'єкти , яка входить до client.model. Іншими словами, Вид будується на підставі Моделі. Для того, щоб послабити їх зчепленість (coupling), взаємозв'язок між пов'язаними Видами, використовується посилання на посередник клас Mediator, якому делегуються події, що приходять із зовнішнього світу від користувача. У випадку, коли є вже готовий інструментарій для побудови програми, варто застосовувати шаблон Adapter при адаптації наявних компонентів Видів. У випадку, коли доводиться самостійно реалізовувати обв'язку API, слід звернути увагу на шаблони Composite, Decorator. Chain of Responsibility і Observer.

Рис. 3.2 Пакет вигляд

3.2. Пакет модель

Пакет client.model на рис. 3.3 містить класи Моделі, які відображаються класами Виду з пакету client.view. У випадку, коли є вже готовий інструментарій для побудови програми, доводиться адаптувати наявні Моделі із пакетів client.model.fact, client.model.meta і client.model.security за допомогою шаблону Adapter до наявних моделями.

Рис. 3.3 Пакет модель

3.3. Пакет посередник

Пакет client.mediator на рис. 3.4 містить клас Mediator, в ролі якого може виступати головний клас програми з методом main (). Зазвичай в складних клієнтських додатках присутні кілька розширюють його класів.

Рис. 3.4 Пакет посередник

3.4. Пакет контролер

Пакет client.controller на рис. 3.5 містить інтерфейс Command, який описує стандартний спосіб ініціювання команд, успадкованих від цього інтерфейсу. У Пакунок містить класи, які містять бізнес-логіку, яка маніпулює моделлю.

Рис. 3.5 пакет контролер

4. Приклад функціонування розподіленої архітектури

Описана вище картина являє собою функціонально-орієнтований погляд на систему і має статичний характер. Для отримання динамічної картини роботи всієї системи слід звернути увагу на діаграму кооперації на рис. 4.1.

Рис. 4.1 Функціонування системи

На даній діаграмі навмисне опущені деталі й моменти розгалуження потоку управління системи для того, щоб виділити головну ідею роботи, не заглиблюючись у деталі. Розпишу подієву модель по кроках:

Користувач впливає на Вид (View) клієнтського додатку.

Вид делегує подія Посередникові (Mediator).

Посередник звертається до Заводу (FactSourceFactory), щоб той створив Proxy-об'єкт, що підтримує інтерфейс FactSourceInterface для роботи з фактами.

Медіатор викликає Контролер (Controller) який відповідає за обробку даного типу події який виник від користувача.

Контролер надсилає запит до створеного Proxy-об'єкту на 3 кроці.

Proxy-об'єкт, що підтримує інтерфейс FactSourceInteface, делегує запит до Джерела Фактів (AbstractFactSource) в ядрі, що знаходиться на стороні сервера додатка. На цьому кроці відбувається мережевий виклик, який проходить через стаб (stub) клієнтського додатку і скелетон (skeleton) сервера програми, де реалізується взаємодія на одній з технологій RMI, CORBA, DCOM або ін

На стороні сервера відбувається аутентифікація за допомогою заводу, що відповідає за безпека (SecurityFactory). Процес аутентифікації відбувається тільки при першому зверненні клієнтського додатку до сервера додатків.

Відбувається процес авторизації, під час якого з'ясовуються права доступу користувача.

Ядро запитує метамодель (MetaModel) у Заводу метаданих (MetaFactory) для опису факту, з яким взаємодіє користувач.

Завод Метаданих витягує запитувану метамодель.

Ядро запитує метамодель на предмет Картридж (FactCartridge), в якому знаходиться факт.

метамодель бере Картридж, в якому знаходиться шуканий факт.

Для доступу до фактів для різних типів джерел даних ядро запитує у Картриджа об'єкт, що підтримує інтерфейс FactDAO.

Картридж запитує цей об'єкт у Заводу Доступу до Фактам (FactDAOFactory), який створює ці об'єкти.

Завод Доступу до Фактам створює запитанийоб'єкт.

Ядро делегує об'єкту запит від Контролера клієнтського додатку.

Об'єкт, що підтримує інтерфейс FactDAO, виробляє зміни факту (Fact).

Управління повертається в Контролер клієнтського застосування, що виробляє корекцію Моделі (Model).

Медіатор надсилає повідомлення про оновлення Моделі Виду, і він робить свою перемальовування.

5. Складність реалізації

Запропонована мною специфікація має точки зіткнення зі специфікацією EJB в плані цілей, але не містить обмеження на архітектуру безпеки, бізнес-об'єктів та їх описів. Специфікація не має вузьку спрямованість на конкретну розподілену технологію, таку як RMI, і визначає архітектуру клієнтських додатків, чого немає в специфікації EJB. Використання вже готових реалізацій специфікації EJB дуже привабливо у порівнянні з самостійною реалізацією, запропонованої мною специфікації, але в силу своїх обмежень може бути відкинута. Для отримання першої версії реалізації специфікації каркаса системи з розподіленою архітектурою було витрачено шість місяців групою програмістів з 6 осіб з 8 годинним робочим днем і 5 денним робочим тижнем. Для тих організацій, які вирішили скористатися даною специфікацією, слід попередньо прорахувати всі плюси і мінуси ввязиванія в цю розробку.

6. Подяки

Висловлюю свою подяку людям, які мали пряме відношення до реалізації специфікації та внесення до неї своїх поправок: Олексій Нєупокєев, Юрій Юдін, Роман Камерлох, Тарас Улаховіч, Геннадій Пестун, Іван Пономаренко. Без участі цих людей дана специфікація ніколи б не була мною отримана.

Список літератури

Гамма Е. Прийоми об'єктно-орієнтованого проектування (патерни проектування). -- Санкт-Петербург: Видавництво «Пітер», 2001. - 368с.

Цимбал А. Технологія CORBA для професіоналів. - Санкт-Петербург: Видавництво «Пітер», 2001. - 624с.

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/