EJB 3.1 @LocalBean против аннотации

Я понимаю разницу между локальным представлением, удаленным представлением и представлением без интерфейса. Я просто не понимаю, в чем разница между "без представления" (без аннотации) и без интерфейса. А также почему я должен аннотировать мой интерфейс с @Local? Что, если я вообще не аннотирую интерфейс, есть ли разница?

Источник

4 ответа

Решение

Правила (из памяти):

  1. Боб имеет @LocalBean аннотация -> бин не имеет интерфейса
  2. Боб имеет @Local аннотация -> боб имеет локальный вид
  3. Боб имеет @Remote аннотация -> бин имеет удаленное представление
  4. Бин не имеет аннотаций представления, но непосредственно реализует интерфейс, который имеет аннотацию @Local -> бин имеет локальное представление
  5. Бин не имеет аннотаций представления, но непосредственно реализует интерфейс, который имеет аннотацию @Remote -> бин имеет удаленное представление
  6. Бин не имеет аннотаций представления, но непосредственно реализует интерфейс, у которого нет аннотаций представления -> у бина есть локальное представление
  7. Бин не имеет аннотаций представления и не реализует интерфейсы -> бин имеет представление без интерфейса

Итак, используя @LocalBean и использование никакой аннотации вообще - оба способа получить представление без интерфейса. Если вам просто нужно представление без интерфейса, то самое простое - не аннотировать. При условии, что вы также не реализуете никаких интерфейсов.

Часть причины @LocalBean существует для добавления представления без интерфейса к компоненту, который также имеет представление интерфейса. Я полагаю, что сценарий, наивысший в сознании авторов спецификаций, был сценарием, в котором у вас есть такой компонент:

@Stateless
public class UserPreferences {
    public String getPreference(String preferenceName);
    public Map<String, String> getPreferences();
}

Где вы хотели бы выставить оба метода локально, но только более грубый getPreferences() удаленно. Вы можете сделать это, объявив удаленный интерфейс только с помощью этого метода, а затем просто ударив @LocalBean на бобовом классе. Без этого вам пришлось бы писать бессмысленный локальный интерфейс, чтобы просто показать оба метода локально.

Или, чтобы посмотреть на это по-другому, @LocalBean существует, потому что существует такая вещь, как представление без интерфейса, и опция без аннотации существует как удобный ярлык.

Источник
  • Удаленные EJB: могут быть доступны с удаленных клиентов (клиенты, работающие на другой JVM, такие как клиенты Swing или JavaFX, которые работают на пользовательском компьютере)
  • Локальные EJB: доступ может быть только из других "компонентов", работающих на той же JVM, например, веб-интерфейсы, другие EJB
  • Представление без интерфейса: то же самое, что и Local, но без указания бизнес-интерфейса
  • Нет аннотации: простой POJO, но не EJB

Представления Local/ No-interface более эффективны, чем удаленные EJB, поскольку ссылки на объекты могут передаваться.

Источник

Я думаю, что замешательство, которое вы / мы чувствуем, является результатом исторической / обратной совместимости (так сказать). Я не могу описать разницу (за исключением того, что спецификация требует реализации для создания интерфейса, если мы используем локальное представление)

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

Блог Oracle перед выпуском EJB 3.1

Источник

Если вас интересуют более технические подробности, позвольте мне сказать, что на самом деле происходит... У вас нет прямого доступа к объекту EJB, это означает, что у вас нет ссылки (адреса) фактического объекта EJB. Когда вы просматриваете или внедряете свой EJB, контейнер предоставляет объект в качестве клиента для этого EJB (мы можем вызвать прокси или Wrapper), и вы вызываете свои бизнес-методы для этого прокси-объекта. (Вот почему вы не должны использовать новое ключевое слово для создания объекта класса EJB)

Теперь для каждого типа аннотации контейнер генерирует прокси разного типа с разными методами и функциями.

@LocalBean (или без аннотации) Ваш прокси-объект имеет:

  • setOptionalLocalIntfProxy()
  • getSerializableObjectFactory()

@LocalВы прокси объект используете локальный вызов и тип com.sun.proxy Итак, оно имеет:

  • getSerializableObjectFactory()
  • isProxyClass()
  • getProxyClass()
  • getInvocationHandler()
  • newProxyInstance()

@RemoteВы Wrapper объект использовать удаленный вызов, и он имеет:

  • readResolve()
  • writeReplace()
  • getStub()
  • getBusinessInterfaceName()
Источник
Другие вопросы по тегам