Изучаем Java EE 7 - [16]

Управляемые компоненты поддерживают функциональность в стиле AOP, обеспечивая возможность перехвата вызова с помощью методов-перехватчиков. Перехватчики автоматически инициируются контейнером, когда вызывается метод управляемого компонента. Как показано на рис. 2.2, перехватчики можно объединять в цепочки и вызывать до и/или после исполнения метода.

Рис. 2.2. Контейнер, перехватывающий вызов и инициирующий метод-перехватчик

Рисунок 2.2 демонстрирует количество перехватчиков, которые вызываются между клиентом и управляемым компонентом. Вы могли подумать, что EJB-контейнер представляет собой цепочку перехватчиков. Когда вы разрабатываете сеансовый объект, вы просто концентрируетесь на бизнес-коде. Но в то же самое время, когда клиент вызывает метод на вашем компоненте EJB, контейнер перехватывает вызов и применяет различные сервисы (управление жизненным циклом, транзакцию, безопасность и т. д.). Без использования перехватчиков вам приходится добавлять собственные механизмы сквозной функциональности и наиболее логичным образом применять их в вашем бизнес-коде.

Слабая связанность и строгая типизация

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

Все эти возможности предоставляются с сохранением безопасности типов. CDI никогда не полагается на строковые идентификаторы, чтобы определить, насколько подходят друг другу объекты. Вместо этого для скрепления компонентов CDI использует строго типизированные аннотации (например, связки квалификаторов, стереотипов и перехватчиков). Применение дескрипторов XML минимизировано до информации, связанной непосредственно с развертыванием.

Дескриптор развертывания

Почти каждая спецификация Java EE содержит опциональный дескриптор развертывания XML. Обычно он описывает, как компонент, модуль или приложение (например, корпоративное или веб-приложение) должны быть сконфигурированы. При использовании CDI дескриптор развертывания называется beans.xml и является обязательным. Он может применяться для конфигурирования определенного функционала (перехватчиков, декораторов, альтернатив и т. д.), но для этого необходимо активизировать CDI. Это требуется для того, чтобы CDI идентифицировал компоненты в вашем пути к классу (так называемое обнаружение компонентов).

Чудо происходит как раз на этапе обнаружения компонентов: в тот момент, когда CDI преобразует объекты POJO в компоненты CDI. Во время развертывания CDI проверяет все JAR- и WAR-файлы вашего приложения и каждый раз, когда находит дескриптор развертывания beans.xml, управляет всеми объектами POJO, которые впоследствии становятся компонентами CDI. Без файла beans.xml в пути к классу (в каталоге META-INF или WEB-INF) CDI не сможет использовать внедрение, перехват, декорацию и т. д. Без этой разметки файл CDI не будет работать. Если ваше веб-приложение содержит несколько файлов JAR и вы хотите активизировать CDI применительно ко всему приложению, то каждому файлу JAR потребуется отдельный файл beans.xml для инициирования CDI и обнаружения компонентов.

Обзор спецификаций по CDI

CDI стал общим основанием для нескольких спецификаций Java EE. Одни спецификации в большой степени полагаются на него (Bean Validation, JAX-RS), другие посодействовали его возникновению (EJB), а третьи связаны с ним (JSF). CDI 1.1 затрагивает несколько спецификаций, но является неполным без остальных: Dependency Injection for Java 1.0 (запрос JSR 330), Managed Bean 1.0 (запрос JSR 342), Common Annotations 1.2 (запрос JSR 250), Expression Language 3.0 (запрос JSR 341) и Interceptors 1.2 (запрос JSR 318).

Краткая история спецификаций CDI

В 2006 году Гевин Кинг (создатель Seam), вдохновленный идеями фреймворков Seam, Guise и Spring, возглавил работу над спецификацией по запросу JSR 299, позднее названной Web Beans (Веб-компоненты). Поскольку она создавалась для Java EE 6, ее пришлось переименовать в Context and Dependency Injection 1.0. При этом за основу был взят новый запрос JSR 330: Dependency Injection for Java 1.0 (также известный как @Inject).

Эти две спецификации взаимно дополняли друг друга и не могли использоваться в Java EE по отдельности. Внедрение зависимостей для Java определяло набор аннотаций (@Inject, @Named, @Qualifier, @Scope и @Singleton), используемых преимущественно для внедрения. CDI дал семантику запросу JSR 330 и добавил еще больше новых возможностей, таких как управление контекстом, события, декораторы и улучшенные перехватчики (запрос JSR 318). Более того, CDI позволил разработчику расширить платформу в рамках стандарта, что ранее не представлялось возможным. Целью CDI было заполнить все пробелы, а именно: