Определение представлений EJB 3.1 (локальный, удаленный, без интерфейса)

В этом посте будут обсуждаться возможные способы определения представлений EJB с помощью аннотаций (в конце я просто упомяну об использовании дескриптора развертывания EJB.) Я сосредоточусь на самых последних представлениях EJB 3.1, исключая устаревшие локальные, удаленные и домашние интерфейсы. Поэтому мы можем выбирать между:

• просмотр удаленного бизнес-интерфейса,
• вид локального бизнес-интерфейса,
• без интерфейса просмотра.

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

Представление локального бизнес-интерфейса

1. Интерфейс имеет аннотацию @Local ; EJB реализует этот интерфейс.

   1 2 3 4

   @Local public interface LocalA {     void localA(); }

   1 2 3 4 5 6

   @Stateless public class MeineEJB implements LocalA {       @Override     public void localA() {} }

   Преимущества:

   • Вам не нужно указывать тип интерфейса в вашем EJB. Вы просто «внедряете» Java, а контейнер делает все остальное.
   • Информация о типе интерфейса тесно связана с интерфейсом, поэтому другим разработчикам ее будет проще понять.
   • Благодаря предложению Java Implements вы можете использовать javac или IDE, чтобы убедиться, что все бизнес-методы EJB реализованы.

   Недостатки:

   • Теперь ваш интерфейс тесно связан с технологией EJB (импорт javax.ejb.* ). Теперь вы должны предоставить клиенту API необходимые библиотеки для его использования.

2. Интерфейс — это простой интерфейс Java без аннотаций; EJB с аннотацией @Local его реализует.

   EJB должен определить, какой интерфейс должен быть представлен как локальный бизнес-интерфейс (для этого есть значение по умолчанию — см. Пункт № 3.)

   1 2 3

   public interface LocalA {     void localA(); }

   1 2 3 4 5 6 7

   @Stateless @Local(LocalA.class) public class MeineEJB implements LocalA {       @Override     public void localA() {} }

   Преимущества:

   • Информация о типе интерфейса слабо связана. Вы можете отправить свой API клиенту и не заботиться о семантике EJB. Если вы скроете это с фасадом, ваш конечный пользователь (даже разработчик) даже не должен знать, что он использует технологию EJB под капотом.
   • Благодаря предложению Java Implements вы можете использовать javac или IDE, чтобы убедиться, что все бизнес-методы EJB реализованы.

   Недостатки:

   • Теперь ваш EJB должен определить все свои бизнес-интерфейсы, используя аннотацию @Local так что это дополнительная работа для вас. Не только вы реализуете интерфейс, но вы должны помнить, чтобы объявить, что ваш EJB предоставляет его. Ничто (с точки зрения javac) не мешает вам @Local интерфейс в аннотацию @Local который на самом деле не реализован вашим EJB.

3. Интерфейс — это простой интерфейс Java без аннотаций; EJB реализует это.

   Поскольку это единственный реализованный интерфейс EJB, контейнер предполагает, что он должен быть локальным бизнес-интерфейсом. Если EJB реализует более одного интерфейса — контейнер не сможет распознать, какой из них является вашим локальным бизнес-интерфейсом.

   1 2 3

   public interface LocalA {     void localA(); }

   1 2 3 4 5 6

   @Stateless public class MeineEJB implements LocalA {       @Override     public void localA() {} }

   Преимущества:

   • Обладает всеми преимуществами 1-го и 2-го подходов, рассмотренных выше.

   Недостатки:

   • Он предполагает поведение по умолчанию контейнера EJB и знания разработчиков об этом. Это не будет работать, если вы используете более одного представления EJB. Более того, он не будет работать, даже если ваш EJB реализует более одного интерфейса (не обязательно представление EJB.)

4. Интерфейс — это простой интерфейс Java без аннотаций; EJB с аннотацией @Local его не реализует.

   Что интересно в этом случае, так это то, что, поскольку вы не используете предложение Java implements , вы можете иметь разные сигнатуры для методов в интерфейсе и EJB. Любое такое несоответствие приведет к исключению, выдаваемому контейнером. Также обратите внимание на отсутствие аннотации @Override при реализации метода бизнес-интерфейса. Это потому, что мы не реализуем никакой интерфейс в терминах Java.

   1 2 3

   public interface LocalA {     void localA(); }

   1 2 3 4 5

   @Stateless @Local(LocalA.class) public class MeineEJB {     public void localA() {} }

   Преимущества:

   • Информация о типе интерфейса слабо связана. Вы можете отправить свой API клиенту и не заботиться о семантике EJB. Если вы скроете это с фасадом, ваш конечный пользователь (даже разработчик) даже не должен знать, что он использует технологию EJB под капотом.

   Недостатки:

   • Имеет все недостатки 2-го подхода, рассмотренного выше.
   • Знание того, что какой-то метод, объявленный вами как интерфейс @Local не реализован, в значительной степени зависит от используемой среды IDE. Intellij IDEA пометит это как ошибку, а AFAIR Eclipse — нет.
   • Это, на мой взгляд, сочетание наиболее важных недостатков и, следовательно, худшего способа определения представления EJB.

Представление удаленного бизнес-интерфейса

Случаи 1, 2 и 4 для представлений локального бизнес-интерфейса также действительны для представлений удаленного бизнес-интерфейса. Точка № 3 является исключением. Контейнер никогда не будет предполагать что-либо об удаленных интерфейсах. Если EJB реализует некоторый интерфейс и не определяет, какой это интерфейс — он всегда будет предполагать, что он локальный.

Вид без интерфейса

Я уверен, что после прочтения вышеупомянутых разделов вы сможете понять плюсы и минусы использования следующих двух подходов для определения представлений EJB без интерфейса. Следовательно, я не буду обсуждать их здесь.

1. EJB @LocalBean как @LocalBean .

   Этот EJB может — но не обязан — реализовывать некоторые интерфейсы (простой Java или бизнес локальные / удаленные интерфейсы). @LocalBean действителен только для класса EJB.

   1 2 3 4 5

   @Stateless @LocalBean public class MeineEJB {     public void localMethod() {} }

2. EJB не имеет специальных аннотаций.

   Контейнер предполагает, что если класс аннотирован как EJB, но не реализует какие-либо интерфейсы и не имеет каких-либо аннотаций, связанных с представлениями, — он предоставит представление без интерфейса.

   1 2 3 4

   @Stateless public class MeineEJB {     public void localMethod() {} }

Дескриптор развертывания EJB (ejb-jar.xml)

Все предыдущие разделы рассматривали представления EJB, определенные с помощью аннотаций. Вы также можете определить представления EJB с помощью дескриптора развертывания ( ejb-jar.xml ). Пример:

Приведенный выше код и DD определяют EJB, представляющий три представления (локальный бизнес, удаленный бизнес и отсутствие интерфейса). Это семантически идентично:

Ссылка: Определение представлений EJB 3.1 (локальных, удаленных, без интерфейса) от нашего партнера по JCG Петра Новицки в блоге домашней страницы Петра Новицкого .