Предположим, например, что набор отдельных EJB-компонентов реализует общую стратегию , определяемую общим бизнес-интерфейсом. В зависимости от результата какого-либо алгоритма выбора (например, бизнес-правила ), выбирается другая стратегия, и, следовательно, в рамках бизнес-процесса будет выполняться другой EJB. В таком сценарии целевой EJB не может быть выбран во время внедрения, поскольку элементы аннотации (такие как @ EJB ) определяются во время компиляции, а дескрипторы развертывания определяются во время развертывания. Единственное решение этой проблемы — программный поиск JNDI.
Будут применяться те же механизмы, которые описаны в предыдущих постах. Ссылки EJB будут объявлены и связаны с именем в частном пространстве имен вашего приложения с помощью аннотации @EJB или соответствующих элементов вашего дескриптора развертывания модуля Java EE.
Поиск в частном пространстве имен приложения
Переносимый способ установить уровень косвенности между пространством имен, используемым в вашем коде поиска, и целевыми EJB-компонентами — это использование личного пространства имен вашего приложения. Этот тип уровня косвенности довольно распространен в платформе Java EE: он используется не только для ссылок на EJB, но и для всех видов ссылок на ресурсы, таких как источники данных JDBC, очереди JMS, сеансы JavaMail и т. Д.
В случае EJB, как видно из нашего предыдущего поста, вы просто определяете частное имя, используемое кодом поиска и внедрения вашего приложения. Это частное имя в области приложения и подэлемент записи JNDI в java: comp / env . С помощью аннотации @EJB и дескрипторов развертывания вы можете установить связь между этим именем и целевым EJB. Единственное отличие состоит в том, что вместо того, чтобы полагаться на контейнер для вставки ссылки в ваш компонент, ваши прикладные алгоритмы будут выбирать соответствующий EJB-компонент и будут его динамически искать.
Как мы видели во второй части этой серии, аннотацию @EJB можно использовать на уровне типа, метода и поля для объявления ссылки на EJB и, необязательно, для привязки ее к целевому бину без необходимости написания каких-либо код дескриптора развертывания.
Если речь идет о динамическом программном поиске JNDI, вместо того, чтобы аннотировать поле (или свойство) в качестве цели внедрения, вы можете аннотировать класс (например, сервлет), чтобы установить ссылку на EJB. В следующем примере мы увидим, как это сделать с помощью аннотации @EJB и дескриптора размещения.
Объявление ссылки на EJB
В тестовом сервлете, который мы использовали в наших предыдущих публикациях, мы можем использовать аннотацию @EJB на уровне класса, чтобы объявить ссылку на EJB в частном имени ejb / ejbLocalRef :
|
1
2
3
4
5
6
|
@EJB(name = "ejb/ejbLocalRef", beanInterface = es.reacts.SessionTest0Local.class, beanName = "EJBServer1.jar#SessionTest1")public class ServletTest1 extends HttpServlet { [...]} |
Аннотация в предыдущем примере функционально эквивалентна следующему фрагменту дескриптора развертывания (в данном случае, файл web.xml ):
|
1
2
3
4
5
6
|
<ejb-local-ref> <ejb-ref-name>ejb/ejbLocalRef</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local>es.reacts.SessionTest0Local</local> <ejb-link>EJBServer1.jar#SessionTest1</ejb-link></ejb-local-ref> |
Самое важное различие между семантикой @EJB в этом примере и в примерах из предыдущего поста состоит в том, что в этом случае мы предоставляем всю информацию, необходимую для установления ссылки и ссылки на целевой EJB, без внедрения или даже не полагаясь на информацию, поступающую от цели внедрения (такой как beanInterface ).
Хотя аннотация применяется на уровне класса, она фактически эквивалентна добавлению соответствующих элементов дескриптора развертывания, и поэтому объявленная ссылка будет доступна во всем модуле Java EE . В этом случае любой другой сервлет в вашем веб-модуле Java EE сможет внедрить или найти тот же EJB, на который ссылается имя ejb / ejbLocalRef :
|
1
2
|
@EJB(name = "ejb/ejbLocalRef")SessionTest0Local lc4; |
Дополнительного «слесарного дела» здесь не требуется, поскольку ссылочная декларация содержит всю информацию, необходимую для разрешения целевого EJB.
EJB Программный поиск
Поскольку ссылка была объявлена и связана, наш код теперь может выполнять поиск JNDI и получать ссылку на желаемый бизнес-интерфейс нашего целевого EJB-компонента. Код поиска JNDI — это хороший код поиска ole, к которому мы привыкли (с небольшой разницей, которую мы укажем позже):
|
1
2
3
4
5
6
|
InitialContext ctx = new InitialContext();Object obj = ctx.lookup("java:comp/env/ejb/ejbLocalRef");if (obj instanceof SessionTest0Local) { SessionTest0Local lc = (SessionTest0Local) obj; [...]} |
(* Обратите внимание, что предыдущий фрагмент был лишен необходимого кода обработки исключений .)
Хорошая новость в EJB 3.0 заключается в том, что вам не нужно сужать ссылку с помощью метода PortableRemoteObject.narrow (), как того требует спецификация EJB v. 2.1. В примере кода мы можем напрямую протестировать ссылку с помощью оператора instanceof и использовать нативное приведение Java для установки ссылки SessionTest0Local .
Нет абсолютно никакой разницы между поиском локальных и удаленных бизнес-интерфейсов. Только в том случае, если вы полагаетесь на дескриптор развертывания, объявление и связывание ссылок EJB будут выполняться с использованием <ejb-ref> или <ejb-local-ref> в соответствии с типом бизнес-интерфейса EJB. Что касается вашего приложения, код поиска будет идентичным.
Узоры
В сценариях, в которых вы не используете EJB-инъекцию и вместо этого полагаетесь на поиск, существуют как преимущества, так и недостатки в использовании аннотаций или дескрипторов развертывания для объявления и ссылки на ссылки EJB.
Преимущества аннотаций в том, что их легче писать и использовать, чем соответствующие элементы дескрипторов развертывания. Более того, что касается моего опыта, поддержка IDE для автозаполнения кода может быть лучшим инструментом, чем некоторые редакторы дескрипторов развертывания, которые в лучшем случае «неясны» (с заметными исключениями, такими как Oracle JDeveloper и NetBeans ‘).
Преимущество дескриптора развертывания заключается в том, что он может централизовать объявления ссылок на ресурсы. Если одна и та же ссылка на EJB используется во всем коде вашего модуля Java EE и не ограничена одним классом, лучшим вариантом будет использование дескриптора развертывания для объявления и ссылки на ссылку EJB (и другого ресурса) и вообще не использовать аннотации , Это выбор дизайна, к которому нужно относиться осторожно. В тех случаях, когда поиск необходим, есть вероятность, что EJB-связывание может быть выполнено на этапах сборки и развертывания приложения. Наличие ссылок, хорошо документированных и объявленных в центральном репозитории, все еще может быть предпочтительнее, чем аннотация @EJB, разбросанная по всему коду, и задача развертывания может быть значительно облегчена.
Ссылка: EJB Programmatic Lookup от нашего партнера JCG Грея из The Grey Blog .