Я намагаюся зрозуміти, яка мета і навіщо нам потрібні різні погляди клієнтів в EJB. Хтось може спробувати пояснити?
Відповіді:
Вигляд віддаленого клієнта
Коли ваш EJB та його клієнти будуть знаходитись у розподіленому середовищі, тобто EJB та клієнти будуть знаходитись на окремих віртуальних машинах Java. Приклад: EJB, розміщені на сервері додатків WebSphere, та сервлети, які споживають API EJB, розміщені на сервері Tomcat.
Місцевий вид клієнта
Тільки тоді, коли гарантується, що інші корпоративні компоненти або клієнти звертатимуться до компонента лише в межах однієї JVM. Наприклад, EJB, а також сервлети, розгорнуті на одному сервері WebSphere.
Перегляд без інтерфейсу
Це майже те саме, що і місцевий клієнт, але є відмінності. У цьому випадку ваш клас bean не повинен реалізовувати інтерфейси перегляду клієнта. Усі загальнодоступні методи класу bean автоматично піддаються дії абонента. подання без інтерфейсу завжди отримує посилання на EJB - так само, як локальні або віддалені види - або за допомогою ін'єкції, або пошуку JNDI; але тип Java посилання на EJB - це тип класу компонента, а не тип локального інтерфейсу. Це зручність, представлена як частина Java EE6.
Різниця між місцевим видом клієнта та видом без інтерфейсу
У випадку перегляду без інтерфейсу, клієнт і цільовий компонент повинні бути упаковані в одному додатку (EAR). У випадку локального подання клієнт може бути упакований в окрему програму, ніж корпоративна програма. Отже, це дає більшу гнучкість щодо дрібного зернистості ваших компонентів.
Ви можете використовувати локальний перегляд клієнта проти подання без інтерфейсу, залежно від сценарію використання API. Дуже ймовірно, що режим без інтерфейсу отримає гнучкі функції в майбутніх специфікаціях.
Причина
Історично чи інакше, клієнт, який бажає скористатися послугами EJB, повинен був "шукати" боб на контейнері (з певними початковими контекстами). Це було тому, що всі виклики здійснюються за допомогою спеціального посилання EJB (проксі-сервера), наданого контейнером. Це дозволяє контейнеру надавати всі додаткові послуги bean, такі як об'єднання, керовані контейнером транзакції тощо. Отже, клієнт не може явно створити екземпляр EJB з newоператором. Перегляд клієнта надається через певні інтерфейси, до яких клієнт мав би доступ. Реалізація проксі на стороні сервера здійснюється на основі цих інтерфейсів. Визначено різні подання клієнта для різних сценаріїв розгортання, як зазначено вище.
new, у підсумку ви отримуєте новий екземпляр. Це все. Цей новий екземпляр не матиме жодної "підтримки" від контейнера з точки зору об'єднання, встановлення його контексту тощо. Ви працюєте самостійно.
Відповідно до розділу 3.2.2 Специфікації EJB 3.1:
Доступ до корпоративного компонента через локальний клієнтський подання повинен підтримуватися лише для локальних клієнтів, упакованих в тій самій програмі, що і корпоративний компонент, що забезпечує локальний клієнтський вигляд. Відповідні реалізації цієї специфікації можуть додатково підтримувати доступ до локального клієнтського подання корпоративного компонента від локального клієнта, упакованого в іншу програму. Вимоги до конфігурації для доступу міжпрограми до подання локального клієнта залежать від постачальника та виходять за рамки цієї специфікації. Додатки, що покладаються на доступ між програмами до локального подання клієнта, не є портативними.
Перегляд без інтерфейсу - це лише зручна функція, яка дозволяє компоненту виставляти локальний вид клієнта без необхідності оголошувати окремий інтерфейс.