Новая версия Windows Azure и аспектно-ориентированное программирование (АОП)
Состав группы разработчиков Aspect.NET
Состав нашей группы разработчиков Aspect.NET приведен на рис. 17.3. Система используется в 26 странах. По АОП и системе Aspect.NET защищено четыре кандидатских диссертации: Д.А. Григорьев – ныне доцент мат-мех. факультета СПбГУ; М.К. Грачев, Р.С. Муханов, Доан Нгуен Ван (Вьетнам); готовятся к защите еще несколько диссертаций. Таким образом, проф. В.О. Сафоновым создана на мат-мех. факультета СПбГУ первая в России научная школа по АОП, которая является одной из ведущих в мире.
На рис. 17.5 приведены ссылки на работающие примеры аспектов из монографии В.О. Сафонова.
На рис. 17.6 приведена обложка книги "Аспектно-ориентированное программирование", учебника В.О. Сафонова, первой на русском языке книги по АОП.
увеличить изображение
Рис. 17.5. Ссылки на работающие примеры аспектов из монографии В.О. Сафонова по АОП
Исследования по бесшовной интеграции аспектов в облачные приложения для новой версии Azure с помощью системы Aspect.NET
Нашей группой под научным руководством автора ведутся передовые исследования по бесшовной интеграции аспектов в облачные приложения для новой версии Windows Azure с помощью системы Aspect.NET.
Наша основная публикация по этой теме {4]: Григорьев Д.А., Григорьева А.В., Сафонов В.О. Бесшовная интеграция аспектов в облачные приложения на примере библиотеки Enterprise Library Integration Pack for Windows Azure и системы Aspect.NET. - Компьютерные инструменты в образовании, 2012, № 4, 3-15. Имеются еще несколько публикаций по этой теме (см. [4]). Материал из данной публикации использован в настоящей главе. Автор выражает благодарность соавторам публикации за сотрудничество.
Идея предлагаемых и реализованных нами методов применения АОП для Windows Azure в следующем.
Система Aspect.NET осуществляет внедрение аспектов в целевую сборку на уровне бинарного кода MSIL, без модификации исходного кода целевого приложения
Библиотека Enterprise Library Integration Pack for Windows Azure [3] – решение компании Microsoft для выделения "сквозной функциональности" при разработке облачных приложений (однако оно требует для этого модификации их исходного кода).
Библиотека Microsoft Enterprise Library представляет собой набор наиболее удачных образцов решения стандартных проблем и также предназначена для реализации "сквозной функциональности". В нее входят следующие функциональные блоки:
- Caching Application Block для поддержки кэширования;
- Cryptography Application Block для поддержки шифрования;
- Data Access Application Block для поддержки работы с базами данных;
- Exception Handling Application Block для реализации стратегий обработки исключений;
- Logging Application Block для поддержки протоколирования;
- Security Application Block для поддержки авторизации и безопасности приложений;
- Validation Application Block для поддержки механизмов валидации данных бизнес-объектов;
В 2011 году компания Microsoft выпустила расширение Enterprise Library Integration Pack for Windows Azure, которое содержит функциональные блоки для управления производительностью (Autoscaling Application Block) и ограничения функциональности под нагрузкой (Transient Fault Handling Block). Программист может реализовать ту или иную "сквозную функциональность", если в исходном коде своего проекта вызовет методы из набора классов соответствующего функционального блока. С точки зрения АОП очевидно, что местоположение этих вызовов в исходном коде целевого приложения является совокупностью точек внедрения для действий соответствующего аспекта.
Чтобы облегчить внедрение (weaving) функциональных блоков в целевое приложение, компания Microsoft представила Unity Application Block – IOC-контейнер с ограниченной поддержкой АОП. Его механизмы позволяют во время исполнения целевой программы перехватывать вызовы заданных методов и передавать управление цепочке методов - "перехватчиков" (interceptors). Цепочка "перехватчиков" может вызываться как перед вызовом целевого метода, так и после него, имея возможность обратится к результату выполнения данного целевого метода.
Кроме того, Unity позволяет разрывать зависимости между конкретным классом и его интерфейсом. Иными словами, за создание конкретного класса отвечает специальная фабрика Unity, что дает возможность задавать правила сопоставления интерфейса и класса не в исходном коде, а в конфигурационном файле. К сожалению, говорить в этом случае о бесшовной интеграции также не приходится, так как процесс применения Unity включает в себя создание Unity-контейнера, а затем обращение к нему за конкретным классом в том месте исходного кода, где требуется получить реализацию для интерфейса.
Проект Aspect.NET, разрабатываемый коллективом авторов с 2004 г. в СПбГУ, также представляет собой аспектно-ориентированную среду разработки программ для платформы Microsoft.NET. Аспекты определяются на метаязыке Aspect.NET ML [1], либо с помощью пользовательских атрибутов в отдельных проектах MS Visual Studio, а их слияние с целевым кодом происходит на уровне сборок статически, т.е. после этапа компиляции. Вначале компилируется сборка с аспектами из которой компоновщик аспектов (weaver) извлекает правила внедрения каждого действия аспекта, содержащиеся в его пользовательском атрибуте AspectAction(). Затем компоновщик анализирует MSIL-код откомпилированной сборки целевого проекта, находит соответствующие места внедрения (сканирование) и вставляет туда действия из аспектной сборки. Операции сканирования и внедрения действий аспектов разделены, что позволяет пользователю просматривать и фильтровать точки внедрения. Весь анализ и модификация .NET - сборок производится с помощью сервисов рефлексии (reflection) и библиотеки Microsoft Phoenix, которая декомпилирует сборку и представляет ее в виде набора высокоуровневых инструкций.
Любое действие можно вставлять перед (ключевое слово %before), после (%after) или вместо (%instead) вызова заданного целевого метода. Название целевого метода задается с помощью регулярных выражений относительно его сигнатуры. Местонахождение точки внедрения внутри конкретного метода или класса можно фильтровать по ключевому слову %within.
Внутри действий можно использовать свойства базового класса Aspect, предоставляющие доступ к контексту точки внедрения, например, "this" и "target" объектам целевого метода, его метаданным (типа MethodInfo), отладочной информации, результату выполнения и пр. Причем компоновщик вставляет в итоговую сборку MSIL-код для передачи контекста только в том случае, если действие аспекта использует его. Аргументы целевого метода передаются через аргументы действия. Таким образом, аспект – это класс производный от служебного базового класса Aspect, а его действиями будут открытые статические методы, помеченные атрибутом AspectAction(). В случае, когда определение аспекта задается на Aspect.NET ML, специальный конвертер переводит его в определение с пользовательскими атрибутами.
В свою очередь, MS Enterprise Library имеет множество готовых функциональных блоков и не требует никаких сторонних инструментов для своей работы, но возможности Unity по их аспектно-ориентированному применению серьезно ограничены. Перед авторами была поставлена задача заменить Unity и реализовать бесшовную интеграцию этих функциональных блоков с помощью Aspect.NET. Это позволило бы объединить сильные стороны двух инструментов, а именно: большой набор готовых аспектов, приемлемая скорость результирующего кода и независимость целевого проекта от АОП-инструмента. Объектом исследования были выбраны Autoscaling Application Block и Transient Fault Handling Block, как наиболее полезные для разработки облачных приложений на платформе MS Azure. По мнению авторов, фокусирование на решении проблем сквозной функциональности в области разработки облачных приложений более перспективно, так как здесь возможности применения аспектно-ориентированного программирования еще не до конца изучены.