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

Question

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

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

Спасибо за любые разъяснения и предложения.

Answer 1

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

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

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

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

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

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

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

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

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

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

Ресурсы

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

Answer 2

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

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

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

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

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

Удачи.

Answer 3

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

@Local Доступ к аннотированным bean-компонентам возможен только в том случае, если они находятся в одном приложении.

@Remote Доступ к аннотированным bean-компонентам возможен в разных приложениях, находящихся в разных jvms или на серверах приложений.

Итак, важно помнить следующее:

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

Answer 4

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

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

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

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