Що таке EJB і що це робить?

Намагалися дізнатися, що таке EJBквасоля, що означає, що їхні екземпляри управляються в басейні, бла-бла. Дійсно не можна їх добре зчепити.

Чи можете ви пояснити мені, що вони є насправді (практично для програміста Java)? Що вони роблять? Які їх цілі? Навіщо насправді їх використовувати? (Чому б просто не дотримуватися POJO?) Можливо, приклад програми?

Будь ласка, зверніться лише до оновленої інформації, тобто EJB 3.1. Подана інформація про EJB може вводити в оману.

Для початківців EJB навчання, будь ласка, зверніть увагу:

EJB засновані на розподілених об'єктах , це стосується фрагментів програмного забезпечення, що працюють на декількох машинах (віртуальних або фізичних), пов'язаних мережею .

Навіщо насправді їх використовувати? (Чому б просто не дотримуватися POJO?)

Якщо вам потрібен компонент, який отримує доступ до бази даних, або отримує доступ до інших ресурсів підключення / каталогу, або отримує доступ до декількох клієнтів, або призначений як служба SOA, EJB сьогодні зазвичай "більший, сильніший, швидший (або принаймні більш масштабований)" і простіше ", ніж POJO. Вони найбільш цінні для обслуговування великої кількості користувачів через Інтернет або корпоративну мережу і дещо менш цінні для невеликих додатків у відділі.

1. Повторне використання / спільне використання логіки для декількох додатків / клієнтів із вільним з'єднанням.
   EJB можна упаковувати у власні банки, розгортати та викликати з багатьох місць. Вони є загальними компонентами. Щоправда, POJO можуть бути (ретельно!) Розроблені як бібліотеки та упаковані у банки. Але EJB підтримують доступ до локальної та віддаленої мережі - у тому числі через локальний Java-інтерфейс, прозорий RMI, повідомлення про асинхрологію JMS та веб-сервіс SOAP / REST, економлячи від залежностей розрізання та вставки jar із декількома (непослідовними?) Розгортаннями.
   Вони дуже корисні для створення служб SOA. Якщо вони використовуються для місцевого доступу, це POJO (з додаванням безкоштовних служб контейнерів). Акт розробки окремого шару EJB сприяє додатковій обережності для максимізації інкапсуляції, нещільного з'єднання та згуртованості та сприяє чистому інтерфейсу (Фасад), захищаючи абонентів від складних моделей обробки та обробки даних.

2. Масштабованість та надійність Якщо ви застосуєте велику кількість запитів від різних викликів / процесів / потоків, вони спочатку розподіляються між доступними екземплярами EJB в пулі, а потім ставлять у чергу. Це означає, що якщо кількість вхідних запитів в секунду більша, ніж може обробити сервер, ми вишукано деградуємо - завжди деякі запити ефективно обробляються, а надлишки запитів змушують чекати. Ми не досягаємо "зриву" сервера - де ВСІ запити одночасно відчувають жахливий час відгуку, плюс сервер намагається отримати більше ресурсів, ніж обладнання та ОС може обробляти &, отже, збої. EJB можуть бути розгорнуті в окремий рівень, який може бути кластеризований - це забезпечує надійність за допомогою переходу з одного сервера на інший, плюс обладнання може бути додано до лінійного масштабування.

3. Управління одночасністю. Контейнер забезпечує автоматичний безпечний доступ до примірників EJB (послідовно) декількома клієнтами. Контейнер управляє пулом EJB, пулом потоків, чергою виклику і автоматично здійснює блокування запису на рівні методу (за замовчуванням) або блокування читання (через @Lock (READ)). Це захищає дані від корупції завдяки одночасним сутичкам «запис-запис» та допомагає послідовно читати дані, запобігаючи зіткнення «читання-запис».
   Це в основному корисно для бобів сеансу @Singleton, де боб маніпулює та обмінюється загальним станом між абонентами клієнтів. Це можна легко перекрити, щоб вручну налаштувати або програмно керувати розширеними сценаріями для одночасного виконання коду та доступу до даних.

4. Автоматизована обробка транзакцій.
   Не робіть нічого, і всі ваші методи EJB виконуються в транзакції JTA. Якщо ви отримуєте доступ до бази даних за допомогою JPA або JDBC, вона автоматично зараховується до транзакції. Те саме для викликів JMS та JCA. Вкажіть @TransactionAttribute (деякийTransactionMode) перед методом, щоб вказати, чи / як цей конкретний метод бере участь у транзакції JTA, переосмислюючи режим за замовчуванням: "Обов'язково".

5. Дуже простий доступ до ресурсів / залежностей через ін'єкцію.
   Контейнер буде шукати ресурси та встановлювати посилання на ресурси як поля екземплярів у EJB: такі, як збережені JNDI з'єднання JDBC, з'єднання JMS / теми / черги, інші EJB, транзакції JTA, контенти стійкості менеджера об'єктів JPA, одиниці стійкості заводських менеджерів JPA, та Ресурси адаптера JCA. наприклад, встановити посилання на інший EJB & транзакцію JTA та менеджер об'єктів JPA та фабрику та чергу з'єднань JMS:

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   Сервлет може викликати цей бін локально, просто оголосивши змінну екземпляра:

   @EJB MyAccountsBean accountsBean;    
   

   а потім просто викликати його методи за бажанням.

6. Розумна взаємодія з JPA. За замовчуванням EntityManager, який вводиться, як зазначено вище, використовує контекст стійкості, що охоплюється транзакціями. Це ідеально підходить для бобів без сеансів без громадянства. Коли викликається метод EJB (без стану), створюється новий контекст стійкості в рамках нової транзакції, всі екземпляри об'єкта об'єкта, отримані / записані в БД, видно лише під час виклику цього методу та ізольовані від інших методів. Але якщо за допомогою методу викликаються інші EJB без громадянства, контейнер розповсюджує та передає їм один і той же ПК, тож ті самі об'єкти автоматично обмінюються послідовно через ПК в одній транзакції.
   Якщо оголошено бін сеансу @Stateful, однакова розумна спорідненість з JPA досягається, оголосивши entitManager розширеним діапазоном: @PersistentContent (unitName = "AccountsPU, type = EXTENDED). Це існує протягом життя сеансу бін, для декількох викликів та транзакцій бін, кешування копій пам'яті об'єктів БД, попередньо отриманих / записаних, щоб їх не потрібно було повторно отримувати.

7. Управління життєвим циклом. Життєвим циклом EJB керує контейнер. За необхідності, він створює екземпляри EJB, очищає та ініціалізує стан стану бія сеансу, пасивує та активує та викликає методи зворотного виклику життєвого циклу, тому код EJB може брати участь у операціях життєвого циклу для придбання та звільнення ресурсів, або виконувати інші дії ініціалізації та відключення. Він також фіксує всі винятки, записує їх у журнал, скасовує транзакції за потребою та викидає нові винятки EJB або @ApplicationExceptions як потрібно.

8. Управління безпекою. Контроль доступу до EJB на основі ролі може бути налаштований за допомогою простого анотації або налаштування XML. Сервер автоматично передає автентифіковану інформацію про користувача разом із кожним викликом як контекст безпеки (головний виклик та роль). Це забезпечує автоматичне виконання всіх правил RBAC, так що методи не можуть бути незаконно викликані неправильною роллю. Це дозволяє EJB легко отримувати доступ до деталей користувача / ролі для додаткової перевірки програм. Це дозволяє підключити додаткову обробку безпеки (або навіть інструменти IAM) до контейнера стандартним чином.

9. Стандартизація та портативність. Реалізації EJB відповідають стандартам Java EE та умовам кодування, сприяючи якості та простоті розуміння та обслуговування. Він також сприяє переносу коду на нових серверах додатків постачальників, гарантуючи, що всі вони підтримують однакові стандартні функції та поведінку, а також відштовхує розробників від випадкового використання фірмових
   функцій непереносного постачальника.

10. Справжній кікер: простота. Все вищезазначене можна виконати за допомогою дуже спрощеного коду - або за допомогою налаштувань за замовчуванням для EJB в Java EE 6, або додавши кілька анотацій. Кодування / промислові особливостей міцності підприємства у власному POJOs буде шлях більш volumous, складними і схильні до помилок. Після того, як ви почнете кодування за допомогою EJB, їх досить легко розробити і надавати чудовий набір переваг "безкоштовної їзди".

У оригінальній специфікації EJB 10 років тому EJB були великими клопотами щодо продуктивності праці. Вони були роздуті, потребували великої кількості артефактів коду та конфігурації та забезпечували приблизно 2/3 переваг, зазначених вище. Більшість веб-проектів фактично їх не використовували. Але це істотно змінилося за 10 років налаштування, капітального ремонту, функціонального вдосконалення та розвитку потокової підкладки. У Java EE 6 вони забезпечують максимальний рівень промислової міцності та простоту використання.

Що не подобається ?? :-) :-)

EJB - це компонент Java, який містить ділову логіку, яку ви розгортаєте в контейнері, і яка отримує переваги від технічних послуг, що надаються контейнером, як правило, декларативним шляхом, завдяки приміткам:

• управління транзакціями: транзакцію можна запустити автоматично до виклику методу EJB та здійснити або повернути назад після повернення цього методу. Цей транзакційний контекст поширюється на дзвінки до інших EJB.
• управління безпекою: може бути перевірена наявність абонента необхідних ролей для виконання методу.
• ін'єкція залежності: інші ЕЖБ або такі ресурси, як менеджер об'єктів JPA, джерело даних JDBC тощо можуть бути введені в EJB.
• паралельність: контейнер гарантує, що лише один потік одночасно викликає метод вашого примірника EJB.
• розповсюдження: деякі EJB можна викликати віддалено, з іншого JVM.
• відмова та балансування навантаження: віддалені клієнти ваших EJB можуть автоматично переадресовувати свій дзвінок на інший сервер.
• управління ресурсами: статеві боби можуть автоматично пасивуватися на диск, щоб обмежити споживання пам'яті вашого сервера.
• ... Мабуть, я забув деякі моменти.

Сподіваюся, що цей документ від Oracle doc допоможе комусь, як я, зрозуміти тему EJB просто.

Що таке Enterprise Bean? Написаний мовою програмування Java, підприємство bean - це компонент на стороні сервера, який інкапсулює ділову логіку програми. Бізнес-логіка - це код, який відповідає цілі програми. Наприклад, у програмі контролю запасів, боби підприємства можуть реалізувати логіку бізнесу методами, що називаються checkInventoryLevel та orderProduct. За допомогою цих методів клієнти можуть отримати доступ до послуг інвентаризації, що надаються додатком.

Переваги Enterprise Beans З кількох причин квасоля підприємства спрощує розробку великих, розподілених додатків. По-перше, оскільки контейнер EJB надає послуги на системному рівні для підприємств-бобів, розробник бобів може зосередитися на вирішенні бізнес-проблем. Контейнер EJB, а не розробник bean, відповідає за послуги на рівні системи, такі як управління транзакціями та авторизація безпеки.

По-друге, оскільки боби замість клієнтів містять ділову логіку програми, розробник клієнта може зосередитись на презентації клієнта. Клієнт-розробник не повинен кодувати підпрограми, що реалізують бізнес-правила або доступ до баз даних. Як результат, клієнти тонші, що особливо важливо для клієнтів, які працюють на невеликих пристроях.

По-третє, оскільки підприємства-боби є портативними компонентами, асемблер додатків може створювати нові програми з існуючих бобів. Ці програми можуть працювати на будь-якому сумісному сервері Java EE за умови використання стандартних API.

Коли використовувати корм для підприємств, вам слід розглянути можливість використання корпоративних бобів, якщо у вашій програмі є будь-яка з наведених нижче вимог:

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

Операції повинні забезпечувати цілісність даних. Підприємство підтримує транзакції, механізми, які керують паралельним доступом до спільних об'єктів.

У додатку будуть різні клієнти. Маючи лише декілька рядків коду, віддалені клієнти можуть легко знайти боби підприємств. Ці клієнти можуть бути худими, різноманітними та численними.

Питання, яке мене найбільше цікавить, - це як і де я можу їх використовувати. Щоб зрозуміти це, нам потрібно спочатку розібратися, які існують типи EJB. Є 2 великі категорії:

1. Сесія квасоля
2. Повідомлення керовані боби

Розглянемо боби сесії. Вони бувають 3-х видів:

1. Stateful - ці компоненти підтримують стан та є специфічними для клієнта у кількох запитах. Розглядайте це як сеанс. Можливе негайне використання - це візки для магазинів або інший тип сеансів (сеанс входу тощо)
2. Без громадянства - це самостійні компоненти, які не зберігають інформацію між запитами, але вони унікальні для користувача. Безпосереднє використання, що спадає на думку - Класи обслуговування на рівні обслуговування . Уявіть собіOrderService . Ще одне велике використання для цього - розкривати веб-сервіси. Знову ж таки, це буде на рівні Сервісу або зовсім окремо.
3. Синглтон - це квасоля, яка існує в одній програмі і створюється один раз і може бути повторно використана / доступна кілька разів. Одразу ж на думку Configurationприходить компонент - де ви можете зберігати конфігурації додатків і отримувати доступ до них, коли вам це потрібно з будь-якого місця.

Тепер решта можливостей або можливостей можна використовувати в різних шарах у будь-яких таких ситуаціях:

• Безпека - ви можете перевірити наявність дозволів із приміткою про викликаний метод. Це може статися як на рівні Сервісу, так і в Контролері, якщо ви цього бажаєте.
• Управління транзакціями - це очевидний кандидат на рівні Сервісу або Постійності
• Ін'єкційна залежність - знову використовуватиметься всюди

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

І так далі. Тепер великий недолік полягає в тому, що ви стаєте дуже залежними від контейнера EJB, і хоча ви можете переключитися між двома базовими реалізаціями, ви не зможете перейти на щось легше - наприклад, Tomcat. Але навіщо ви хочете пожертвувати всіма благами?