Статья: Спецификация каркаса информационной системы с распределенной архитектурой
Рис. 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).
Медиатор посылает сообщение об обновлении Модели Виду, и он производит свою перерисовку.