EJB - когда использовать удаленные и/или локальные интерфейсы?

Ответ 1

Я очень новичок в Java EE, и я пытаюсь понять концепцию локальных интерфейсов и удаленных интерфейсов.

В исходных версиях спецификации EJB EJB были "предположительно" удалеными компонентами, и единственным способом их вызова было сделать удаленный вызов, используя семантику RMI и все связанные с этим накладные расходы (сетевой вызов и объект сериализация для каждого вызова метода). Клиенты EJB должны были заплатить это снижение производительности даже при размещении на той же виртуальной машине с контейнером EJB.

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

Мне сказали, что одним из больших преимуществ Java EE является то, что его легко масштабировать (что, я считаю, означает, что вы можете развернуть разные компоненты на разных серверах)

Java EE может масштабироваться, но это не обязательно означает распределение компонентов. Вы можете запустить приложение Web + EJB в кластере без разделения уровня Web и уровня EJB.

Предполагаете ли вы использовать удаленные интерфейсы, если вы ожидаете, что ваше приложение будет иметь разные компоненты на разных серверах? И используйте локальные интерфейсы, если ваше приложение будет только на одном сервере?

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

(...) Начните с использования локальных интерфейсов и постепенно обновляйтесь до удаленных интерфейсов, если это применимо?

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

Я предлагаю проверить перечисленные ниже ресурсы (2 первых из них довольно старые, но по-прежнему актуальны, 2 других - более свежие).

Ресурсы

• Обзор выпуска спецификаций EJB 2.0 от Tyler Jewell
• Под капотом J2EE Clustering от Wang Yu
• Масштабирование приложений Java EE от Wang Yu
• Масштабирование приложений Java EE - часть 2 от Wang Yu

Ответ 2

Хотя я согласен с большей частью того, что написано выше, я хотел бы немного доработать "как начать" идеи.

Мое предложение для вас - никогда не программировать непосредственно на интерфейсы EJB в вашем коде. Всегда используйте обычный, ориентированный на бизнес интерфейс, программу для него (это значит, что у вас есть методы вызова кода на бизнес-ориентированном интерфейсе) и предоставить код "клея" EJB в качестве встраиваемой реализации. Ваша программа должна быть ориентирована на бизнес-логику, а не на детали реализации, такие как EJB.

Таким образом, вы можете легко переключаться между удаленными и локальными реализациями - и если вы используете контейнер IoC, такой как Spring, вы можете сделать это только с помощью конфигурации.

Особое примечание о переключении с локального на удаленный: обратите внимание, что между ними существует несколько семантических различий. Например, вызов метода EJB через его "удаленный интерфейс" приводит к тому, что аргументы передаются по значению, а при вызове через "локальный интерфейс" приводятся аргументы, передаваемые по ссылке. Это основное различие; поэтому, если вы "начинаете с локального", убедитесь, что вы проектируете свою систему так, чтобы она учитывала семантику "remote".

Если ваш дизайн зависит от методов EJB, изменяющих объекты с передачей, тогда вам будет сложно "переключиться на удаленный" позже; возможно даже невозможно.

Удачи.

Ответ 3

Согласно EJB Spec 3.2, EJB может быть либо локальным, либо удаленным. В то же время бизнес-интерфейс не может быть одновременно локальным и удаленным.

@Local аннотированный beans может быть доступен только в том случае, если они находятся в одном приложении.

@Remote аннотированный beans может быть доступен для разных приложений, находящихся в разных jvms или серверах приложений.

Таким образом, важно помнить, что:

• Если класс bean содержит аннотацию @Remote, то все реализованные интерфейсы должны быть удалены.
• Если класс bean не содержит аннотации или если указано аннотация @Local, то весь реализованный интерфейс предполагается локальным.
• Любые интерфейсы, явно определенные для bean, которые не содержат интерфейса, должны быть объявлены как @Local.
• Выпуск EJB 3.2 имеет тенденцию обеспечивать большую детализацию ситуаций, когда локальные и удаленные интерфейсы должны быть явно определены.

Ответ 4

Это может ответить на ваши проблемы:

Как правило, вашей Enterprise Java Bean потребуется просмотр удаленного клиента в когда вы планируете использовать Bean в распределенных средах. В частности, это те случаи, когда клиент, который будет работать с ним будет находиться другая виртуальная машина Java (JVM). В случае вид удаленного клиента, вызывающий любой метод из удаленного дома интерфейс и/или интерфейс удаленного компонента будут обрабатываться через удаленный метод вызова (RMI).

EJB может использовать локальное представление клиента только в том случае, если действительно гарантировано, что другое предприятие beans или клиенты будут обращаться только к Bean в пределах одиночный JVM. Если это так, такой доступ будет осуществляться с помощью прямые вызовы методов, а не RMI.

Источник: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text