Средства разработки приложений


функционирования распределенной архитектуры


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

функционирования распределенной архитектуры

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

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

  1. Пользователь воздействует на Вид (View) клиентского приложения.

  2. Вид делегирует событие Посреднику (Mediator).

  3. Посредник обращается к Заводу (FactSourceFactory), чтобы тот создал Proxy-объект, поддерживающий интерфейс FactSourceInterface для работы с фактами.

  4. Медиатор вызывает Контроллер (Controller) который отвечает за обработку данного типа события пришедшего от пользователя.

  5. Контроллер посылает запрос к созданному Proxy-объекту на 3 шаге.

  6. Proxy-объект, поддерживающий интерфейс FactSourceInteface, делегирует запрос к Источнику Фактов (AbstractFactSource) в ядре, находящемуся на стороне сервера приложения. На этом шаге происходит сетевой вызов, который проходит через стаб (stub) клиентского приложения и скелетон (skeleton) сервера приложения, где реализуется взаимодействие на одной из технологий RMI, CORBA, DCOM или др.

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

  8. Происходит процесс авторизации, во время которого выясняются права доступа пользователя.

  9. Ядро запрашивает Метамодель (MetaModel) у Завода Метаданных (MetaFactory) для описания факта, с которым взаимодействует пользователь.

  10. Завод Метаданных извлекает запрашиваемую Метамодель.

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

  12. Метамодель берет Картридж, в котором находится искомый факт.

  13. Для доступа к фактам для разных типов источников данных ядро запрашивает у Картриджа объект, поддерживающий интерфейс FactDAO.

  14. Картридж запрашивает этот объект у Завода Доступа к Фактам (FactDAOFactory), который создает эти объекты.

  15. Завод Доступа к Фактам создает запрашиваемый объект.

  16. Ядро делегирует объекту запрос от Контроллера клиентского приложения.

  17. Объект, поддерживающий интерфейс FactDAO, производит изменения факта (Fact).

  18. Управление возвращается в Контроллер клиентского приложения, производящий коррекцию Модели (Model).

  19. Медиатор посылает сообщение об обновлении Модели Виду, и он производит свою перерисовку.


Содержание раздела