Этот цикл статей, состоящий из шести частей, посвящен Cairngorm – микроархитектуре с открытым исходным кодом и адресован Flex разработчикам. В нем я хочу объяснить внутреннюю суть Cairngorm, подход к проектированию на основе Cairngorm, а также описать те проекты, реализация которых на основе Cairngorm может быть наиболее успешной.
На примере Cairngorm Магазина я объясню подход Adobe Consulting к анализу, оценке и разработке насыщенных интернет-приложений (RIA) на основе Cairngorm. Я также объясню идеи, заложенные в Cairngorm и мы вместе с вами создадим с нуля Интернет-магазин.
В последней статье, я продемонстрирую одну из многих выгод, которую получают разработчики, основывая свои RIA приложения на Cairngorm, с помощью добавления новой функции в готовый Интернет-магазин.
Конечно же, Cairngorm это не единственный способ построения насыщенных Интернет приложений. Однако Adobe Consulting помог многочисленным заказчикам и партнерам успешно реализовать масштабные проекты на Flex, основываясь на уже имеющихся разработках заказчиков и информации изложенной в этой статье.
Это введение раскроет вам проблемную область Cairngorm, начиная с мотивации разработки на Cairngorm и его концепций до проектирования своего собственного приложения на этой, признанной многими авторитетами, и поддерживаемой микроархитектуре.
Вместо ковыряния в коде, первая часть вводит вас в проблемную область архитектуры Cairngorm и дает понимание ее основ. Я расскажу о фреймворках и объясню разницу между программными фреймворками и архитектурными. Потом я произведу обзор паттернов проектирования и подведу вас к пониманию микроархитектуры. В заключении я вкратце расскажу о необходимости Cairngorm, его начало и историю.
В частях 2-6 мы с вами будем разрабатывать клиентскую часть приложения для розничной торговли с помощью Flex и Cairngorm на основе существующей J2EE серверной инфраструктуры.

ЧТО ТАКОЕ ФРЕЙМВОРК

В сфере разработки программного обеспечения термин «фреймворк» сильно перегружен и вместе с этим часто используемый. Когда разработчики создают большое количество кода и начинают его повторно использовать в других проектах, они начинают определять этот код как фреймворк. Это приводит к существованию большого количество типов фреймворков: постоянные (статичные) фреймворки, транзактные фреймворки, фреймворки журналирования, проблемно-ориентированные фреймворки, анимационные фреймворки, фреймворки для тестирования, и тому подобное.
Но прежде чем объяснить отличие фреймворка Cairngorm, я хочу обратить ваше внимание на отличие программных фреймворков от архитектурных фреймворков.

Программные фреймворки

Flex есть яркий пример программного фреймворка. Действительно, продукт Flex 2.0 имеет все отличительные качества программного фреймоворка (который Adobe внутри называет «app model») в своей архитектуре. Фреймворк Flex 2.0 предоставляет большой набор классов с высокоуровневой функциональностью, которые разработчик может использовать в собственном проекте. Например, Flex 2.0 предоставляет API для работы с Collections Data (сложные типы данных, состоящие из других типов - прим. перев.), которые дают возможность управлять коллекциями данных. Разработчик может собирать необходимые данные в единый объект, который будет характеризовать его приложение. И конечно же Flex, как и любой другой программный фреймворк, предоставляет возможность управления историей, управление разметкой проекта, управление видом курсора, перехват исключений, возможность интернационализации, журналирования и тому подобное.
Если фреймворк предоставляет библиотеки высокоуровневых классов с большой степенью гибкости их использования, или когда фреймворк предоставляет сервис уровня приложения, и может использоваться в различных проектах – я называю такой фреймворк «программным».
Еще один хороший пример программного Фреймворка это фреймворк FAST, который Adobe Consulting довольно успешно использует в проектах своих клиентов и партнеров. Фреймворк FAST (см. статью Джона Беннетта «Быстрая разработка с помощью Flex Application Toolkit» http://www.adobe.com/devnet/flex/articles/fast_userguide.html) предоставляет программные службы для логирования и трассирования, расширенных пользовательскими данными библиотечных RPC классов в Flex 1.x.

Архитектурные Фреймворки

Архитектурные фреймворки есть нечто совсем иное. Обычное предназначение архитектурного фреймворка состоит не в предоставлении каких-то дополнительных служб для приложения а в создании инфраструктуры самого приложения, на которую можно было бы «натянуть» это приложение. Это похоже на создание скелета, некой движущейся структуры, на которую можно нацепить мышцы и плоть, которые в данном примере являются бизнес логикой.
Другими словами, архитектурный фреймворк предоставляет некую отправную точку для создания технической структуры вашего приложения.

ИСПОЛЬЗОВАНИЕ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ

Сложно говорить о программной архитектуре без упоминания о паттернах проектирования, этом важном явлении в области разработки ПО.
Не вдаваясь в подробности паттернов проектирования, можно сказать что выражение «Ничто не ново в этом мире» как нигде более справедливо в области программной инженерии. Очень часто программист в своей работе сталкивается с похожими задачами и создает похожие решения. Такое повторение решения вы можете назвать паттерном, что означает одинаковый подход к проектированию и решению задачи.

Привлекательность паттернов проектирования

А теперь внимание: когда разработчик сталкивается с паттерном проектирования, каталог реализаций этих паттернов оказывается очень мощным инструментом в решении поставленной инженерной проблемы. Еще чаще разработчик сталкивается с целым клубком задач и пытается изобрести новый паттерн. Здесь применима старая пословица «Если у тебя в руках молоток, то все кажется гвоздями». В этом случае вы услышите термин «перегрузка паттерна», что означает, что разработчик отказывается от разработанного класса и отказывается от сотрудничества, а пытается все впихнуть в Factory (Фабрика), Flyweight (Приспособленец), Observer (Наблюдатель), Decorator (Декоратор).
Однако правильное использование паттернов проектирования приносит большую выгоду. Паттерн проектирования не просто дает решение проблемы, а указывает направление реализации. Например, если вы видите в коде паттерн Singleton (Синглтон, Одиночка), вы сразу понимаете, что будет всего один экземпляр этого класса. Точно также, если вы видите паттерн Factory, вы понимаете, что существует некое множество других классов, созданием которых будет заниматься эта фабрика.
Поднимаясь по уровням технической архитектуры – с начального уровня детализации до высокоуровневой системы, скажем, вертолета – вы можете увидеть процесс разработки в виде повторяющегося процесса. Так же как Мандельброт (основатель фрактальной геометрии – прим. перев.), вы можете опознавать структуры более высокого порядка на основе описания более примитивных структур. Также и паттерны объединяются повторением, давая решение более высокого уровня для более сложных проблем.

Микроархитектура как объединение паттернов проектирования

Шаблон проектирования дает конкретное решение конкретной проблемы. Например: паттерн Синглтон дает нам уверенность в том, что будет всего один экземпляр этого класса. Набор паттернов, последовательно взаимодействующих друг с другом, дают решение более обширной задачи. Например: «Как мне получить жест пользователя и убедится что класс рабочего (паттерн Worker – прим. перев.) берет ответственность за исполнение»? Или: «Как мне сосредоточить бизнес логику, которая может использоваться в разных контекстах приложения на стороне клиента, даже если это вызывает различные службы на сервере»?
Когда вы начнете объединять шаблоны проектирования в системы более высокого порядка, пусть даже весьма примитивные по своему действию, вы будете называть это «микроархитектурой».
Теперь перейдем от абстрактных рассуждений о программных фреймворках, архитектурных фреймворках, паттернах проектирования и микроархитектурах к нашей теме. Когда Adobe Consulting говорит о фремворке Cairngorm, мы подразумеваем архитектурный фреймворк – отправную точку для технической архитектуры, достаточно абстрактную чтобы применять ее в различных проектах Flex RIA средней и большой сложности.
Более того, когда мы говорим о фреймворке Cairngorm, мы не имеем в виду какую-то монолитную архитектуру, которая ограничивает вашу свободу как разработчика ради решения технической проблемы. Скорее мы подразумеваем следующее:
- компактный программный фреймворк, который предусматривает некий целостный и последовательный подход к разработке Flex RIA
- использование небольшого количества необходимых паттернов, которые в процессе взаимодействия являются чем-то большим, нежели просто набором шаблонов
- микроархитектура для разработки RIA – отправная точка для технической архитектуры, предназначенной для решения задачи тем же успешным способом, который использовался неоднократно
И как вы увидите ниже, это все благодаря тому, что «мы стоим на плечах гигантов».

КРАТКАЯ ИСТОРИЯ CAIRNGORM

Софтверная консалтинговая компания iteration::two, которую я основал совместно с Алистером МакЛеодом, хорошо зарекомендовала себя в среде разработок программного обеспечения на основе J2EE и ее подходы к решению задач оказались подходящими для разработок RIA. Мы применили свои наработки для реализации RIA с помощью Flash, Flash Remoting и J2EE – в тот ранний период истории развития RIA, к которому мы так нежно и с ностальгией относимся, как C++ программисты относятся к программированию на ассемблере 6809.
Заимствуя часть шаблонов проектирования из библиотеки «Core J2EE Pattern Catalog» Sun Microsystems (http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html), мы первыми представили эти паттерны вниманию Flash сообщества в нашей книге «Reality J2EE: Architecting for Macromedia Flash MX» (Pearson Education, 2003). Совместно с выходом Flash MX 2004, мы описали эти паттерны в главе «ActionScript 2.0 Design Patterns for RIA Development» в «Macromedia Flash MX 2004 ActionScript 2.0 Dictionary» (Macromedia Press, 2003).
С развитием RIA технологии от дизайнерского подхода к разработке до декларативной программной модели Flex, большая часть идей применения этих паттернов осталась. Однако программная модель Flex дает нам более элегантный способ для воплощения этих паттернов. Более того, некоторые паттерны, имевшие большую ценность для Flash RIA разработчиков (например, паттерн ViewHelper), утратили свою значимость, и были нами заменены другими (например, ModelLocator), свойственными для Flex.
На форуме MAX 2004 мы заявили свое намерение о создании фреймворка Cairngorm, как проекта с открытым исходным кодом для Flex. Это решение нашло широкую поддержку в среде программистов.

ЧЕМУ ВАС УЧИТ CAIRNGORM

Микроархитектура Cairngorm предъявляет три основные требования, которые мы всего советуем нашим клиентам и партнерам как лучшую практику программирования:
- Обрабатывать пользовательские жесты на клиенте;
- Инкапсулировать бизнес логику и взаимодействие с сервером;
- Управлять состоянием приложения на клиенте и отображать это состояние в пользовательском интерфейсе.
Cairngorm реализует микроархитектуру (т.е. набор паттернов), которая последовательно решает эти повторяющиеся задачи проектирования.
После того, как вы прочтете этот цикл статей, вы научитесь следующему:
- Как паттерны Front Controller и Command реализуют микроархитектуру «Service to Worker», которая слушает пользовательские запросы и отвечает на них;
- Каким образом взаимодействуют паттерны Business Delegate и Service Locator, так что вы можете повторно использовать бизнес логику, а также инкапсулируют ее, позволяя разработчикам клиентской и серверной части легко связать взаимодействие приложений на сервере и клиенте, не зависимо от технической реализации серверных служб, будь то WebService, Enterprise JavaBeans, ColdFusion, или REST-архитектура использующая XML через HTTP;
- Как паттерн Value Object из J2EE сотрудничает с паттерном Model Locator, давая элегантное решение того, каким образом хранить состояние на клиенте, с насыщенным и анимированным пользовательским интерфейсом.

ТЕКУЩЕЕ СОСТОЯНИЕ CAIRNGORM

Текущая версия Cairngorm – 0.99 (на момент 2006 года; сейчас (2008) уже есть версия 2.2.1 для Flex 3 – прим. перев.). Он никогда не будет выпущен в версии 1.0, поскольку iteration::two была вовлечена в ряд поглощений, сначала со стороны Macromedia a потом и Adobe Systems. Более того, с выходом Flex 2.0, ActionScript 3.0, численных изменений в основе фреймворка Flex, множества новых потрясающих служб (включая Flex Data Services), и эволюцией самого Комитета Cairngorm (а сейчас он является частью основных консультантов и инженеров Adobe, и большим сообществом вокруг Adobe) – Adobe Consulting сфокусировалась назад выпуском комплексного релиза Cairngorm 2.0, который бы использовал всю мощь Flex 2.0.
Но, не смотря на это, ключевые концепции Cairngorm остаются теми же. Изменилась только реализация внутренних механизмов для использования новых свойств Flex 2.0, например, таких как Flex Data Services, Flex RPC Services. Для тех, кто уже работает с Flex 2.0 в Adobe Labs, мы регулярно выпускаем альфа релизы Cairngorm 2.0.
Замечание: в заключительной части этого цикла, я обсуждаю критерии принятия решения для использования Cairngorm. Мы ни в коем случае не убеждаем, кого бы то ни было в том, что Cairngorm это единственный способ построения RIA приложений. Мы даже не настаиваем на том, что это является лучшей практикой проектирования. И, конечно же, кто-либо может предлагать свои подходы, которые будут противоположны рекомендациям Cairngorm.
Все что мы требуем от вас, это сначала попытаться понять саму проблему, которую пытается решить Cairngorm, до того как начинать решать ее с помощью Cairngorm. Если вы только начинаете свое изучение Flex 2.0 для построения RIA приложений, я настоятельно рекомендую вам сначала освоить все то множество новых инструментов и техник этой технологии, прежде постижения сложных моментов связанных с Cairngorm.
Нельзя сказать, что Cairngorm очень сложный. Напротив, но вы должны уже уметь строить простые RIA приложения, которые не требуют каких-то специальных микроархитектур, для того чтобы вы смогли ощутить преимущества использования Cairngorm.
Прочтение вами частей 2-6 этого цикла позволит нам удостовериться, что и новички и опытные Flex программисты одинаково понимают проблемы создания RIA, которые решает Cairngorm. Мы хотим объяснить вам как можно доходчивее, и приведенные примеры кода элегантного решения с помощью Cairngorm, надеемся, помогут вам эфективно использовать Cairngorm для решения своих задач.

ЧТО ДАЛЬШЕ