46156 (762237), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 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/

Характеристики

Список файлов статьи