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

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



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



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

722   4  

4 ответов:

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

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

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

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

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

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

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

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

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

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

ресурсы

167  
2010-09-28 18:59:41

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

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

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

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

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

удачи.

44  
2010-10-03 07:48:42

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

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

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

так что важные вещи, чтобы иметь в виду являются:

  1. если класс bean содержит @Remote аннотация, то все реализованные интерфейсы должны быть удаленными.
  2. если класс bean не содержит аннотаций или если @Local аннотация указана, то все реализованные интерфейсы считаются локальными.
  3. все интерфейсы, явно определенные для компонента, который не содержит интерфейса, должны быть объявлены как @Local.
  4. освобождение от EJB 3.2, как правило, обеспечивают больший уровень детализации для ситуации, когда локальные и удаленные интерфейсы должны быть явно определены.
14  
2016-12-11 13:24:12

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

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

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

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

7  
2013-11-11 02:42:40

Comments

    Ничего не найдено.
Click here to cancel reply.