AOP@Work: Сравнение инструментальных программ для AOP, часть 2

Средства разработки

Во этой второй части своего сравнения АОП-инструментов эксперт по аспектно-ориентированному программированию Мик Керстен (Mik Kersten) концентрирует внимание на интеграции этих инструментов со средой разработки и компоновки, включая детальное сравнение функциональных возможностей их IDE. Для того, чтобы помочь вам принять окончательное решение, автор заканчивает статью обзором грядущих изменений этих быстро развивающихся продуктов и приводит обобщение сильных и слабых сторон каждого из них. Отметим, что в этой статье обсуждаются также и недавно анонсированное слияние проектов AspectJ и AspectWerkz.

Mik Kersten , Архитектор инструментальных средств АОП и консультант, University of British Columbia

Мик Керстен (Mik Kersten) является ведущим экспертом по аспектно-ориентированному программированию и участником проектов AspectJ и AJDT eclipse.org. В качестве ученого-исследователя Xerox PARC он создал IDE-поддержку для AspectJ. Он заканчивает получение степени Ph.D. в University of British Columbia, где делает IDE более аспектно-ориентированным. Он также консультирует компании, создающие средства разработки, относительно использования и поддержки аспектно-ориентированной технологии.



08.02.2005

В первой части сравнения АОП-инструментов я показал, как четыре ведущих АОП-инструмента (AspectJ, AspectWerkz, JBoss AOP и Spring AOP) реализуют основные АОП-механизмы. И хотя все они похожи в применении модели точек соединения, pointcut, advice, и inter-type-объявлений, существуют значительные компромиссы в реализации АОП-синтаксиса в каждом из них. Как я показал в первой части, синтаксические решения не только влияют на то, как выглядит программирование аспектов (многословный синтаксис или более лаконичный, pointcut в виде кода или в виде аннотаций, сохранение в том же самом исходном файле как advice или локализация вместе с конфигурацией аспекта в XML), но также влияют и на семантику. Здесь я продолжу исследование различных подходов, но внимание сконцентрирую на том, как рассмотренные выше решения влияют на интеграцию инструментов в общий процесс и среду разработки.

Я начну с более глубокого рассмотрения AspectJ-расширения языка Java™, уделяя особое внимание всем за и против такого стиля кода в отношении способа компоновки аспектов и их статической проверки. Мы также рассмотрим различные подходы инструментов к компоновке аспектов (weaving), используя новую программу тестирования AWBench для выяснения их влияния на производительность.

Возможно, самой важной темой, обсуждаемой во второй части сравнения АОП-инструментов, является поддержка IDE. Я приведу сравнение всех функциональных возможностей поддержки IDE и визуальное сравнение работы двух подключаемых модулей IDE. Я также рассмотрю каждый инструмент с точки зрения документации и поддержки библиотек, которые являются важными факторами при выборе реализации новой технологии.

В окончании статьи я поразмышляю о возможном будущем этих инструментов и приведу обзор основных сильных и слабых сторон каждого из них. В таблице 1 обобщены ключевые аспекты интеграции со средой разработки, которые будут детально обсуждаться на протяжении всей статьи.

Таблица 1. Сравнение AOP-инструментов: интеграция со средой разработки
Сравнение AOP-инструментов: интеграция со средой разработки

Если вы не читали первую часть, то, возможно, захотите сделать это сейчас.

Об этом цикле статей

Цикл статей AOP@Work предназначен для разработчиков, обладающих некоторыми основными знаниями аспектно-ориентированного программирования и желающих расширить или углубить их (материалы по основам АОП можно найти в разделе "Ресурсы"). Как и большинство статей developerWorks, статьи этого цикла очень практичны: из каждой статьи вы получите новые знания, которые можно сразу же использовать.

Каждый из авторов статей этой серии был выбран из-за превосходных знаний или компетентности в АОП. Многие авторы являются участниками рассматриваемых в статьях проектов или инструментальных средств. Каждая статья рецензируется, чтобы гарантировать справедливость и точность выраженной в ней точки зрения.

Связывайтесь, пожалуйста, с авторами лично, чтобы прокомментировать их статьи или задать о них вопрос. Чтобы прокомментировать цикл статей в целом, вы можете связаться с ее ведущим Николасом Лесицки (Nicholas Lesiecki). Дополнительные материалы по АОП можно найти в разделе "Ресурсы".

О статье

Эта статья предназначена не для освещения какого-либо одного инструмента, а для критичного и непредвзятого выявления сильных и слабых сторон каждого инструмента. Хотя автор является участником проекта AspectJ, были проведены консультации с лидерами проектов других АОП-инструментов, чтобы гарантировать справедливое представление обсуждаемых технологий.

Компоновка аспектов

Первым вопросом, возникающим при выборе АОП-инструмента, независимо от того работаете вы с IDE или компонуете при помощи Ant и командной строки, является вопрос, насколько хорошо он интегрируется со средой компоновки. Ключевым отличием инструментов в этом вопросе является использование расширения языка. AspectJ предлагает стиль кода, являющегося расширением языка программирования Java, в то время как остальные три инструмента используют комбинацию обычного синтаксиса Java и основанные на аннотациях языки аспектов. С точки зрения интеграции AspectJ-расширение языка программирования Java является преимуществом, поскольку объявления аспектов имеют такую же лаконичную форму и также просты в редактировании, что и объявления классов. С другой стороны, расширение языка Java – это не простое решение, поскольку каждая инструментальная программа, которая работает с исходными Java-файлами, должна быть расширена для понимания аспектов. В следствии этого, несмотря на наличие большого набора инструментальных средств AspectJ, которые рассматривались при сравнении функциональных возможностей, пакет программ не закончен.

С точки зрения среды компоновки основным отличием между инструментами является то, что AspectJ вынужден предоставлять свой собственный компилятор, в то время когда остальные используют стандартный Java-компилятор. Компилятор AspectJ расширяет компилятор Eclipse Java и может быть запущен независимо от Eclipse из командной строки, либо при помощи подключаемых модулей Eclipse и других IDE. Компилятор AspectJ компонует AspectJ и Java-код, находящийся в файлах ".java" или ".aj", и создает обычный байткод Java. И хотя существуют некоторые отрицательные стороны в необходимости нового компилятора, имеется огромное преимущество в обеспечении статического контроля pointcut.

Статический контроль pointcut

Java-программисты при работе с классами очень рассчитывают на статический контроль. Это означает, что не нужно задумываться о правильности написания названия метода, - компилятор сразу же покажет ошибку. Без статического контроля такие ошибки не выявляются до времени исполнения. AspectJ имеет полный статический контроль всех объявлений аспектов, поэтому компилятор AspectJ немедленно укажет на ошибочно написанную ссылку в pointcut. Другие АОП-инструменты в различной степени контролируют корректность объявлений аспектов, но не предлагают статического контроля pointcut ни при использовании аннотаций, ни при использовании XML. Это может привести обычного Java-программиста к необходимости постоянно концентрировать внимание на XML-значениях и ошибках отладки во время исполнения. Забытая в pointcut скобка во время исполнения может привести к необходимости трассировки стека, что сделать значительно труднее, чем просто исправить ошибку, обнаруженную (и указанную) при компиляции.

Используя компилятор AspectJ, вы получаете все преимущества статического контроля, который ожидаете от Java-кода, но применительно к аспектам. Иначе нужно быть очень внимательным при вводе pointcut-выражений и привыкнуть запускать программы для обнаружения ошибок, что может быть весьма проблематично, принимая во внимание сложный синтаксис pointcut-выражений.

На рисунке 1 можно увидеть отличия способов обработки двумя инструментами ошибки отсутствия правой круглой скобки в pointcut. Верхняя половина рисунка показывает, как появляется ошибка в AspectJ, а нижняя - в AspectWerkz.

Рисунок 1. Обнаружение синтаксической ошибки в AspectJ и в AspectWerkz
Обнаружение синтаксической ошибки в AspectJ и в AspectWerkz

Компилятор AspectJ активно анализирует код во время его набора, немедленно указывая ошибку отсутствия скобки. В AspectWerkz эта ошибка не может быть обнаружена до времени исполнения. Как видите, этот тип синтаксических ошибок требует намного больше времени на отладку в инструментах, не имеющих статического контроля pointcut. Но возникает еще более общая и трудная для обнаружения проблема в случае таких ошибок, как неправильный ввод имени типа в pointcut. Без статического контроля АОП-среда просто перестает работать правильно и не вызывает никакого advice. Выяснение, что же произошло не так (особенно на первых порах работы с АОП и pointcut), может быть чрезвычайно длительным процессом. Имея статический контроль, компилятор AspectJ выдает предупреждение, указывающее, что имя типа или сигнатура не может быть найдена. Как мы рассмотрим позже, можно ожидать улучшений в поддержке статического контроля в новых версиях инструментов.

Дальнейший анализ среды компоновки

Лаконичность объявлений аспекта в инструменте должны помочь определить преимущества статического контроля этого инструмента. Например, Spring AOP требует существенного количества XML-связей для создания advice. Чем больше ручного связывания требует инструмент. тем больше времени вы, возможно, потратите на связывание и его отладку, особенно при наличии большого числа аспектов. Эта проблема может быть решена при автоматическом генерировании XML-связей. Ниже мы обсудим эту функцию подключаемого модуля JBoss AOP Eclipse.

Если вы выбрали AspectJ, то должны перейти на его компилятор во всех Java-проектах, в которых вы хотите использовать аспекты. Это может быть проблематично для некоторых проектов (например, в случаях, когда используемый для компоновки серийного продукта компилятор указывается централизовано). Но с другой стороны компилятор AspectJ именно и предназначен для замены Java-компилятора. Еще одним предметом для обсуждения являются издержки компилятора, вызванные дополнительной поддержкой аспектов, которые варьируются для каждого инструмента. Мы детально рассмотрим этот вопрос в следующем разделе. И, наконец, вы должны всегда помнить, что расширение языка в AspectJ требует расширения для AspectJ всех связанных с компоновкой инструментальных средств, использующихся в проекте. Это означает, что многие имеющиеся в наличии средства, анализирующие Java-код, не будут работать с кодом AspectJ (например, программы для составления метрик и отчетов, программы для контроля зависимостей и стиля, различные средства поддержки контроля версий).

Каковы плюсы и минусы расширения языка для интеграции компоновки?

В этом разделе я перечислю основные плюсы и минусы расширения языка в AspectJ с точки зрения интеграции компоновки:

  • - Инструментальные средства, работающие с обычным Java-кодом, должны быть расширены для работы с кодом аспектов.
  • - Необходим другой компилятор.
  • + Расширенный Java-компилятор обеспечивает полный статический контроль всего кода аспектов.
  • + Написание и отладка pointcut значительно упрощаются.

Хотя у такого подхода, использующего расширение языка, есть недостатки, некоторые положительные стороны могут применяться в будущем как для аннотаций, так и для XML-стиля. Обеспечение этих преимуществ для аннотационного стиля является основной мотивацией объединения в @AspectJ команд разработчиков AspectJ и AspectWerkz. Этот проект продемонстрирует, что статический контроль может работать для аннотационного стиля при использовании АОП-компилятора. В настоящее время единственным качественным АОП-компилятором, пригодным для коммерческого применения, является компилятор AspectJ, хотя существуют и другие компиляторы, пригодные для исследования. Обратите внимание, что многие вопросы, связанные с необходимостью другого компилятора, присущи всем инструментам. Проблемы, которые могут возникнуть из-за компилирования новых байткодов, влияют также на изменение этих байткодов во время компоновки, загрузки или исполнения. Как будет рассмотрено в следующем разделе, такой процесс компоновки аспектов является фундаментальным для всех АОП-инструментов, поскольку он дает возможность модульной реализации пересекающихся процессов.


Компоновка аспектов и производительность

Так же как ООП-программы могут быть скомпилированы и выполнены при помощи различных механизмов (например, интерпретация или компиляция в байткод, или в объектный код), АОП-инструменты предлагают различные подходы к компоновке и выполнению аспектов. Компоновщик аспектов (weaver) обеспечивает взаимосвязи, которые вызывают автоматическую активизацию advice, как указано в аспекте при помощи pointcut. Компоновщики аспектов могут принимать в качестве входной информации код в исходном или бинарном виде. Компоновка аспектов влияет на производительность и масштабируемость, зависящих главным образом от того, где происходит процесс компоновки аспектов в жизненном цикле приложения. Компоновка аспектов может происходить в следующие моменты времени:

  • Время компоновки - Как часть стандартной компиляции, если ООП-компилятор расширен до АОП, или как этап пост-компиляции.
  • Время загрузки - Аналогично компоновке байткодов аспектов во время компиляции, но производится во время загрузки классов.
  • Время исполнения - Механизм перехвата и прокси-механизм обеспечивают средство сопоставления pointcut для определения необходимого момента вызова advice.

AspectJ и AspectWerkz поддерживают компоновку аспектов во время компиляции и во время загрузки, хотя AspectJ больше уделяет внимания первой, а AspectWerkz второй. JBoss AOP и Spring AOP используют компоновку аспектов во время исполнения, применяя динамические прокси и перехватчики для активизации аспектов. Обратите внимание, что технология Java VM может быть также расширена для поддержки компоновки аспектов во время исполнения, хотя это все еще находится на стадии исследований. Ключевым преимуществом использования среды перехвата во время исполнения является то, что она природным способом расширяется для поддержки развертывания аспектов на лету. Это означает, что применяемый advice может быть разрешен и запрещен во время исполнения.

Развертывание аспектов на лету является ключевой особенностью JBoss AOP, который предоставляет консоль управления сервером приложений для разрешения и запрета аспектов. Она также доступна и в Spring AOP. Аналогичные расширения модели компоновки аспектов (во время компиляции и во время загрузки) AspectWerkz поддерживают развертывание на лету. В AspectJ такое разрешение и запрет аспектов необходимо делать при помощи условия "if" в advice или при помощи условных ("if") pointcut. Для описания развертывния на лету иногда используется термин "динамическое АОП", но нужно отметить, что этот термин может ввести в заблуждение, поскольку все АОП-инструменты поддерживают динамическую модель точек соединения. Также стоит отметить тот факт, что Spring AOP полностью основывается на механизме прокси. Это делает инструмент подходящим для крупномодульных пересекающихся процессов, но чистый основанный на прокси АОП-инструмент не может быть использован для объявления тонко настроенных точек соединения, таких как вызовы метода или установка полей. С другой стороны, прокси Spring AOP могут быть использованы без какой-либо компоновки аспектов во время компиляции и загрузки, что может быть полезным для некоторых реализаций сервера приложений.

Анализ производительности

Ключевым моментом любого обсуждения АОП и производительности является то, что аргументы против производительности реализаций АОП все те же, что приводились несколько лет назад против объектно-ориентированного программирования. Вообще говоря, код с аспектами выполняет то же самое, что и чистое объектно-ориентированное решение, когда пересекающийся код рассеивается по системе. В большинстве корпоративных приложений, время выполнения которых в основном зависит от удаленных вызовов и обращений к базе данных, обычно нет необходимости беспокоиться об издержках использования любого АОП-инструмента.

Стоит рассмотреть недавно выпущенную программу тестирования производительности AWBench для АОП-инструментов (см. раздел "Ресурсы"). Для понимания характеристик производительности мы должны рассмотреть, как различные подходы к компоновке аспектов и компиляции, применяемые в АОП-инструментах, влияют на производительность.

AspectJ имеет издержки компиляции с точки зрения использования памяти и времени, поскольку он выполняет основное планирование во время компиляции. Это может быть заметным и потенциально проблематичным в больших проектах, особенно из-за того, что пересекающаяся природа аспектно-ориентированных зависимостей часто означает необходимость перекомпиляции большой части системы при изменениях pointcut. Но это также означает, что во время исполнения должна быть выполнена лишь небольшая дополнительная работа для соответствующих pointcut. Еще один выигрыш в производительности во время исполнения является результатом статического указания параметров точек соединения в AspectJ и AspectWerkz. Это дает существенное повышение производительности, поскольку к контексту точек соединения можно обращаться напрямую. В противоположность этому основанные на перехвате способы работы JBoss AOP и Spring AOP во время исполнения должны выполнить больше работы. В результате AWBench оценивает активизацию advice в AspectJ как более быструю, чем в AspectWerkz, JBoss AOP и Spring AOP. Но AspectJ имеет самые больше издержки производительности во время компиляции, AspectWerkz меньше, JBoss AOP еще меньше, а Spring AOP вообще не имеет.

Проблемы производительности при перехвате

Каковы самые главные проблемы производительности реализаций АОП (JBoss AOP и Spring AOP), основанных на использовании техники перехвата и прокси?

  • + Незначительное использование памяти и времени при компоновке.
  • - Издержки активизации advice во время исполнения, необходимые для определения соответствия pointcut.

Как и любые другие приведенные здесь оценки производительности, они должны приниматься с определенной долей осторожности и не должны рассматриваться отдельно от используемого приложения. Например, обычные крупномодульные аспекты, используемые с Spring AOP, вряд ли приведут к каким-либо заметным издержкам. Ни один из рассматриваемых инструментов не имеет слишком уж плохих результатов. Старые инструменты AspectJ и AspectWerkz должны были быть более оптимизированными, и в других версиях это исправлено. Компиляторы АОП являются также относительно новым изобретением, и мы замечаем увеличивающуюся степень оптимизации, которую сообщество разработчиков вносит в такие реализации как AspectJ, так что можно ожидать дальнейшего улучшения времени компоновки.


IDE интеграция

Целью IDE интеграции является облегчение написания и компоновки аспектно-ориентированных программ в вашем любимом IDE. Для того, чтобы это произошло, вы должны иметь возможность вызывать компилятор АОП или компоновщик аспектов (weaver) из вашего IDE. Второй ключевой заботой IDE-поддержки является облегчение навигации и понимания пересекающейся структуры системы.

При редактировании pointcuts необходимость запуска системы и проверки результатов для поиска задействованных точек соединения является очень длительной по времени процедурой. Параллельный вопрос, который часто задают разработчики при первом изучении АОП: "Как я узнаю, какой эффект производит аспект в моей системе? Что если кто-либо еще проверяет определенные аспекты, которые влияют на что-то, с чем работаю я?" Инструменты поддержки отвечают на эти вопросы, указывая, когда advice воздействует на точку соединения. Это означает, что при работе с методом вы видите все advice, которые влияют на метод. Напротив, когда вы пишете аспект, вы сразу видите, на какие точки соединения он воздействует. Рассмотрим, как современные Java IDE обеспечивают удобные средства навигации из метода ко всем методам, которые переопределяют его. Поддержка таких объектно-ориентированных инструментов делает внутреннюю структуру системы явной. IDE-поддержка в АОП проявляет структуру пересекающихся процессов, что делает работу с аспектами такой же легкой, как и работа с объектами.

Сравнение подключаемых модулей

Каждый из инструментов предлагает различную степень поддержки IDE, что может быть важным для правильного выбора инструмента для вашего проекта. Краткий обзор подключаемых IDE-модулей AspectJ и JBoss AOP в действии даст вам представление о поддерживаемых функциях. В следующем разделе я более детально рассмотрю подключаемые IDE-модули инструментов.

На рисунке 2 изображено, как подключаемый модуль для Eclipse AspectJ Development Tools (AJDT) отображает структуру пересекающихся процессов в редакторе вместе с видами, которые расширяются для отображения объявлений аспектов и их воздействий. За подробным описанием этих функциональных возможностей и большим количеством скриншотов вы можете обратиться к статье по AJDT в разделе "Ресурсы".

Рисунок 2. Подключаемый модуль AspectJ Development Tools (AJDT) для Eclipse V1.2.0
Подключаемый модуль AspectJ Development Tools (AJDT) для Eclipse V1.2.0

Ключевые моменты подключаемого модуля AJDT перечислены ниже; номера в списке соответствуют меткам на рисунке:

  1. Package Explorer показывает аспекты и объявления аспектов. Pointcut и advice появляются со своими собственными пиктограммами, которые указывают тип advice (например, before, after).
  2. Editor показывает структурированные аннотации, что позволяет переходить из аспекта к членам advised. Всплывающее вспомогательное меню показывает контекст всех точек соединения, доступных телу advice.
  3. Document Outline представляет структуру пересекающихся процессов для активного редактора, показывая advice и объявления inter-type, которые влияют на соответствующие точки соединения. Aspect Visualiser, видимый чуть ниже Outline в данном сжатом скриншоте, показывает глобальные воздействия пересекающихся процессов по всему пакету или проекту и подсвечивает строки исходного кода, задействованные advice.
  4. Методы, задействованные advice, отображают межстрочные аннотации, которые могут быть использованы для перехода к соответствующему объявлению аспекта. Все другие задействованные точки соединения показывают такую же структуру (например, типы, задействованные объявлениями inter-type, и вызовы, задействованные advice).

Аналогично подключаемому модулю AJDT подключаемый модуль JBoss AOP предоставляет возможность навигации по структуре пересечений при помощи видов. На рисунке 3 вы можете увидеть, что подключаемый модуль JBoss AOP для Eclipse предлагает некоторые из таких же функциональных возможностей, что и подключаемый модуль AJDT. Он также имеет две дополнительные возможности: вид Aspect Manager, который может быть использован для инспектирования связей pointcut, и GUI для создания основанных на перечислении pointcut. В таблице 2 приведено полное сравнение функциональных возможностей подключаемых модулей.

Рисунок 3. Подключаемый модуль JBoss Eclipse V1.0.1
Подключаемый модуль JBoss Eclipse V1.0.1

Ниже перечислены некоторые ключевые моменты подключаемого модуля JBoss AOP; номера в списке соответствуют меткам на рисунке 3:

  1. В Package Explorer advice показываются как обычные Java-члены.
  2. Aspect Manager представляет собой графический вид файла jboss-aop.xml, что уменьшает проблемы, связанные с отсутствием статического контроля, такие как необходимость ручного редактирования XML. Он также предоставляет удобный вид пересекающейся структуры программы.
  3. Дополнительное контекстное меню элементов Java предоставляет возможность их выбора для включения в pointcut без необходимости какого-либо редактирования выражения pointcut.

Сравнение возможностей

В таблице 2 обобщено текущее состояние IDE-возможностей четырех инструментов. Также приводятся сведения по доступным для каждого из них библиотекам и документации.

Таблица 2. Поддержка IDE, библиотеки и документация
Поддержка IDE, библиотеки и документация

Следующие примечания описывают ключевые возможности IDE-поддержки каждого инструмента:

  • AspectJ - в AspectJ основной поддерживаемой средой IDE является Eclipse. Подключаемые модули для Oracle JDeveloper, Borland JBuilder и Sun NetBeans также обеспечивают различную степень поддержки AspectJ. Однако версии для JBuilder и NetBeans в данный момент разрабатываются не слишком активно, а потому отстают от версий языка AspectJ. Важной программой, поставляемой с AspectJ, является ajdoc, генерирующая документацию в стиле Javadoc для программ AspectJ. ajdoc представляет структуру пересечения, по которой можно перемещаться так же как в изображенном на рисунке 3 виде Document Outline, в виде доступных для навигации ссылок в документации HTML-формата. Ассистент содержимого в редакторе является недавно добавленной возможностью, полезной при написании аспектов, особенно для тех, кто еще не очень хорошо знаком с языком и различными элементарными pointcut.
  • AspectWerkz - AspectWerkz обеспечивает подключаемый модуль для Eclipse начального уровня. Совершенствование подключаемого модуля отстает от основной реализации AspectWerkz, и реальная поддержка IDE от AspectWerkz не ожидается, хотя это и предвосхитило совместные усилия с @AspectJ.
  • JBoss AOP - JBoss AOP также делает акцент на поддержку Eclipse. Подключаемый модуль JBoss AOP предоставляет Aspect Manager, который облегчает редактирование конфигурационных XML-файлов. Вид Advised Members предоставляет возможность навигации по пересечению. JBoss также имеет новый UI динамического развертывания аспектов, обеспечивающий JBoss AOP функцией изменения во время исполнения применяемого advice. Отмечу, что подключаемый модуль JBoss AOP выпущен недавно, а потому пока не совершенен и в этом смысле еще отстает от остальной среды JBoss AOP.
  • Spring AOP - подключаемый модуль Spring Eclipse может быть полезен при редактировании спецификации аспектов в XML-файле, но он не обеспечивает какую-либо относящуюся к АОП функциональность.

Для запуска и отладки все инструменты полагаются на существующие Java-отладчики. Отладка программ, использующих аспекты, работает хорошо во всех инструментах, включая те, которые не имеют развитой поддержки IDE (AspectWerkz и Spring AOP). Это означает, что установка точек прерывания в advice и пошаговая отладка работает также как и для обычных Java-классов.

Функциональность, которой вам, возможно, будет не хватать

Поддержка рефакторинга в настоящее время отсутствует во всех подключаемых модулях IDE. В результате этого, если название метода изменяется, pointcut, который соответствовал этому методу, может остановить сопоставление. Это одна из областей, где дает о себе знать обратная сторона расширения языка. В то время как AspectJ должен предоставлять свою собственную поддержку рефакторинга для переименований, с небольшим расширением, другие подходы могут комбинироваться с существующей поддержкой рефакторинга. Поскольку инструменты, основанные на аннотациях и XML, должны использовать полностью квалифицированные Java-pointcut в виде строк, они также могут использовать средства рефакторинга, способные переименовывать полностью квалифицированные Java-ссылки, встроенные в XML-файлы и аннотации.

Становится доступной в IDE и поддержка UML-схем, несмотря на то, что программы таких схем все еще активно обсуждаются. В настоящее время программа просмотра UML совместима с AspectJ или любым другим АОП-инструментом. Если вы используете средство просмотра UML для AspectJ, оно, возможно, не будет работать, поскольку ожидает обычного Java-кода. В противоположность этому АОП-инструменты, основанные на обычном Java-коде, оперируют с аспектами как с обычными классами. Это приносит минимальную пользу, поскольку не будут показаны интересные взаимосвязи между advice и воздействуемыми точками соединения, или дополнительные члены, добавленные в объявлениях inter-type.

Документация и библиотеки

Кроме поддержки IDE наличие документации и библиотек также является важным фактором вашего выбора. Каждый из инструментов предлагает интерактивную документацию, хотя среда Spring предлагает несколько разбросанную и направленную на конкретную реализацию документацию по функциональности своего АОП. "J2EE без EJB" и другие книги по среде Spring должны заполнить этот пробел очень скоро. AspectJ является наиболее хорошо документированным АОП-инструментом, с шестью печатными книгами. Отмечу, что состояние доступной документации просто отражает длительность существования проекта.

Spring AOP предлагает отличную поддержку библиотек. Интеграция со средой Spring означает, что усиливаются аспекты внедрения зависимостей (dependency injection), обеспечивается развитая библиотека перехвата транзакций, и поддерживаются некоторые интересные аспекты сторонних разработчиков, например Acegi Security Framework. Библиотеки Spring AOP также имеют преимущество переносимости между серверами приложений, а развитая модульность среды облегчает процесс настройки для усиления АОП поддержки. JBoss AOP обеспечивает отличную интеграцию со остальной средой JBoss и стеком JEMS, а также имеет самый богатый набор доступных в настоящее время библиотек аспектов. К ним относятся поддержка JBoss Cache, J2EE a la carte, JBoss remoting, асинхронные аспекты и XML-аспекты. В настоящее время AspectJ и AspectWerkz не включают в себя какие-либо библиотеки, хотя при использовании этих инструментов сторонними разработчиками были созданы некоторые библиотеки. Предоставить поддержку библиотек обещается в следующих версиях.


Совсем рядом

Последним фактором, который вы захотите рассмотреть при выборе АОП-инструментов является вопрос "что потом?". Все инструменты развиваются быстрыми темпами, многие рассмотренные проблемы решаются в текущих реализациях. Более того, сильные стороны одного подхода распространяются на другие. Например, просмотр пересекающихся процессов, который был реализован в AspectJ, сейчас предлагается в JBoss AOP, а вскоре появится и в других инструментах. Усилия @AspectJ отфильтруют многие успешные приемы AspectJ в аннотационный стиль AspectWerkz. Будет предложена возможность взаимодействия между стилем расширения языка и стилем аннотаций, предоставляя выбор синтаксиса языка разработчику.

В будущем исследования по рефакторингу АОП дадут результаты, которые можно будет использовать во всех инструментах. UI для графического выбора и управления pointcut получит выгоду от общего набора эвристик, которые могут преобразовать результаты выбора и поиска в pointcut. UML-виды начнут показывать АОП-объявления и ассоциации. Поддержка этих новых функций всеми инструментами будет возможна благодаря сближению ведущих АОП-инструментов.

В долгосрочном плане производительность должна быть снята с повестки дня. Так же как разработчики не беспокоятся об издержках диспетчеризации виртуальных методов, они не будут беспокоиться об издержках активизации advice. В большой степени ситуация такова и в данный момент времени, а станет еще лучше, поскольку компоновщики аспектов улучшаются и становятся более тесно связанными с JIT и VM.

Две другие тенденции не рассматриваются, но их сохранение тоже желательно. Во-первых, модель точек соединения в АОП и механизмы pointcut имеют применимость и вне языков программирования для других средств, которые могут получить преимущества от использования лаконичного языка описания событий времени исполнения. Поскольку внедрение инструментов АОП продолжается, использование pointcut должно стать обычным в таких средствах как отладчики и профайлеры. Например, точки останова могли бы быть установлены в отдельном потоке управления. Другая тенденция связана с управляемой моделями разработкой (MDD, model-driven development). Поскольку понятия пересечения в системах являются фундаментальными, MDD-инструменты получат выгоды от использования пересекающейся структуры и генерирования аспектов.

Вот список конкретных функциональных возможностей, наличия которых можно ожидать в готовящихся версиях АОП-инструментов:

  • AspectJ и AspectWerkz - AspectJ 5 будет поддерживать в pointcut родовые типы (generic). Синтаксис @AspectJ будет поддерживать стиль аннотаций AspectWerkz.
  • JBoss AOP - Функции статической типизации параметров, улучшение производительности, библиотеки и лучшая поддержка IDE.
  • Spring AOP - Улучшение производительности, возможность взаимодействия с pointcut AspectJ и пакетирование некоторых служб Spring AOP в виде AspectJ служб.

Итоги

Мы рассмотрели преимущества и недостатки АОП-инструментов. Как решить, какой инструмент выбрать для вашего конкретного проекта? Каковы основные проблемы, которые могут возникнуть при выборе конкретного подхода? Приведу обзор сильных и слабых сторон каждого инструмента; он может помочь вам сделать окончательный выбор. Я начну с напоминания всех “за” и “против” ручного кодирования пересекающихся процессов и работы с АОП-инструментами.

Все инструменты и ручное кодирование

  • - Расширенные IDE-функции, такие как рефакторинг, пока не поддерживаются.
  • + Аспекты свойственны сложным системам, а без АОП-инструментов реализация таких систем может стать не надежной и тяжелой в развитии.
  • + Пересечения становятся явными, легкими для обдумывания и изменения.

AspectJ

  • - Расширение языка требует использования расширенного компилятора и сопутствующих инструментальных программ.
  • - Отсутствие библиотек.
  • + Лаконичные объявления аспектов и статический контроль pointcut.
  • + Развитая IDE-интеграция.
  • + Исчерпывающая документация.

AspectWerkz

  • - Менее лаконичные объявления аспектов и pointcut.
  • - Отсутствие статического контроля для pointcut.
  • - Отсутствие библиотек.
  • + Схожие с AspectJ механизмы без расширения языка.
  • + Поддержка развертывания аспектов "на лету".

JBoss AOP

  • - Отсутствие статического контроля для pointcut.
  • - Расширенные IDE-функции, такие как рефакторинг, пока не поддерживаются.
  • + Доступен богатый набор библиотек корпоративных аспектов, который интегрирован с развитыми библиотеками JBoss и JEMS.
  • + IDE-поддержка уменьшает необходимость ручного кодирования XML.
  • + Поддержка динамического развертывания аспектов.

Spring AOP

  • - Могут использоваться только объекты, созданные посредством прокси-механизмов среды.
  • - Не подходит для тонко настроенных аспектов.
  • - Отсутствует IDE-поддержка для работы с аспектами.
  • + Простая модель точек соединения хорошо подходит для крупномодульных аспектов и проста в изучении.
  • + Интегрируется со средой Spring и легко принимается существующими пользователями Spring.
  • + Переносимость библиотек аспектов между серверами приложений.

Заключение

Текущее состояние АОП-инструментов является впечатляющим по размаху, а рассмотренные здесь четыре инструмента особенно интересны в силу их нынешнего состояния и ожидаемого развития. Выбранные для сравнения инструмента достаточно развиты и пригодны для коммерческой разработки, а также хорошо поддерживаются.

Тщательный анализ соотношения преимуществ и недостатков, проведенный в этом состоящем из двух частей сравнении АОП-инструментов, поможет вам решить, какой из них наиболее подходит для ваших проектов. Я рассмотрел ключевые отличия этих инструментов в вопросах их работы с объявлениями аспектов, компоновки аспектов и интеграции в процесс компоновки; рассмотрены также основные вопросы производительности и преимущества IDE-интеграции. Кроме того, я привел обзор всех “за” и “против” расширения Java-языка, обсудил тему его возрастающей важности для Java-разработчиков и обратил внимание на некоторые направления развития АОП-инструментов.

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

В следующем месяце ждите появления следующей статьи в серии AOP@Work: "Метаданные и АОП: Совершенное соответствие" Рамниваса Ладдада (Ramnivas Laddad).

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=96655
ArticleTitle=AOP@Work: Сравнение инструментальных программ для AOP, часть 2
publish-date=02082005