EJB - коли використовувати віддалені та / або локальні інтерфейси?

Я дуже новачок у Java EE і намагаюся зрозуміти концепцію локальних та віддалених інтерфейсів. Мені сказали, що однією з головних переваг Java EE є те, що її легко масштабувати (що, на мою думку, означає, що ви можете розмістити різні компоненти на різних серверах). Це те, куди надходять віддалені та локальні інтерфейси? Чи повинні ви використовувати віддалені інтерфейси, якщо очікуєте, що ваша програма має різні компоненти на різних серверах? І використовувати локальні інтерфейси, якщо ваша програма розміщуватиметься лише на одному сервері?

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

Дякуємо за будь-які роз’яснення та пропозиції.

Я дуже новачок у 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 інші - більш новими).

Ресурси

• Під кришкою кластеризації J2EE Ван Ю
• Масштабування програм Java EE від Ван Ю
• Масштабування додатків Java EE - Частина 2 Ван Ю

Хоча я згоден з більшістю написаного вище, я хотів би трохи уточнити ідеї "як почати".

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

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

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

Якщо ваш дизайн покладається на методи EJB, що змінюють передані об'єкти, то вам було б складно "пізніше перейти на віддалений"; можливо, навіть неможливо.

Удачі.

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

@Local до анотованих бобів можна отримати доступ, лише якщо вони знаходяться в одній програмі.

@Remote анотовані боби можна отримати в різних додатках, що знаходяться в різних jvms або на серверах додатків.

Тож важливі речі, про які слід пам’ятати:

1. Якщо клас квасолі містить @Remote анотацію, то всі реалізовані інтерфейси мають бути віддаленими.
2. Якщо клас квасолі не містить анотацій, або якщо @Local анотація вказана, то всі реалізовані інтерфейси вважаються локальними.
3. Будь-які інтерфейси, чітко визначені для біна, який не містить інтерфейсу, повинні бути оголошені як @Local.
4. Версія EJB 3.2 надає більш детальну інформацію для ситуацій, коли локальний та віддалений інтерфейси мають бути чітко визначеними.

Це може відповісти на ваші проблеми:

Як правило, для вашого 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