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


180

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

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

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

Ответы:


186

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

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

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

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

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

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

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

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

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

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

Ресурсы


2
Я нашел этот вопрос интересным. Что вы имели в виду, что «переключение на удаленные интерфейсы не является абсолютно обязательным»? Означает ли это, что когда вы добавляете нового клиента вне той же JVM, вам не нужно создавать удаленный интерфейс?
Мохамида

2
@Josek Спасибо, рад, что тебе понравилось @mohamida Я немного изменил формулировку. Я имел в виду, что вы можете кластеризовать объединенную структуру.
Паскаль Thivent

1
Спасибо за ответ и дополнительные ресурсы, они были очень полезны. Кажется, что есть несколько способов масштабирования веб-приложения ... то есть, распределение компонентов (что я понимаю как разделение разных уровней на разные JVM?) Или использование балансировки нагрузки (при которой было бы включено все приложение). многочисленные серверы?) и я полагаю, вы могли бы использовать комбинацию обоих? Вы случайно не знаете хороших книг на эту тему? Еще раз спасибо!
Брайан ДиКаса

2
@ Брайан It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?Да, это именно так. Do you, by chance know of good books on this topic?К сожалению, нет, я не знаю абсолютного ресурса "ZE", если он есть. Я добавил больше ресурсов с некоторыми ссылками, хотя.
Паскаль Thivent

ссылка на первый ресурс мертва
Вячеслав Добромыслов

48

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

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

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

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

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

Удачи.


2
звучит как еще одна причина, чтобы минимизировать изменчивость на эффективную Java. это поможет гибкости «переключиться на удаленный» для интерфейса типа RMI с EJB?
Thufir

19

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

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

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

Поэтому важно помнить следующее:

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

1
Вопрос: Можете ли вы использовать @Localдля вызова EJB в другом приложении (JAR, WAR, EAR), но в той же JVM?
Carlitos Way

@PritamBanerjee Любая идея о Carlitos Wa, я также сталкиваюсь с той же проблемой. EJB находится в другом кластере, а приложение клиентского сервлета - в другом.
Гови С

@GovindaSakhare Я не совсем уверен в этом. Извините :(
Притам Банерджи

7

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.