EJB 3.1 @LocalBean vs no annotation

Ответ 1

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

• Bean имеет аннотацию @LocalBean → bean имеет вид без интерфейса
• Bean имеет аннотацию @Local → bean имеет локальный вид
• Bean имеет аннотацию @Remote → bean имеет удаленный вид
• Bean не имеет аннотаций вида, но непосредственно реализует интерфейс, который имеет @Local аннотацию → bean имеет локальное представление
• Bean не имеет аннотаций вида, но непосредственно реализует интерфейс, который имеет аннотацию @Remote → bean, имеет удаленный просмотр
• Bean не имеет аннотаций вида, но непосредственно реализует интерфейс, который не имеет аннотаций вида → bean имеет локальное представление
• Bean не имеет аннотаций вида и не реализует интерфейсов → bean имеет вид без интерфейса

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

@LocalBean (или без аннотации) У вашего прокси-объекта есть:

• setOptionalLocalIntfProxy()
• getSerializableObjectFactory()

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

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

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

• readResolve()
• writeReplace()
• getStub()
• getBusinessInterfaceName()