Введення в Java EE

Сьогодні поговоримо про те, що це таке Java EE: з чого складається, які особливості архітектури Java EE додатків, і наведемо описи різних технологій даної платформи. Тема велика сама по собі, але на азах ми не зупинимося. Наприкінці проведемо невелике порівняння Java EE зі Spring Framework і відповімо на питання: "що краще вчити" (спойлер: звичайно ж, вчити потрібно все =)) Почнемо з основ.

Java EE – що це?

Java EE – це платформа, побудована на основі Java SE, яка надає API та середовище часу виконання для розробки та запуску великомасштабних, багаторівневих, масштабованих, надійних та безпечних мережних додатків. Подібні програми називають корпоративними (Enterprise applications), оскільки вони вирішують проблеми, з якими стикаються великі бізнеси. Однак використовувати подібні програми та переваги, які дає Java EE, можуть не лише великі корпорації та урядові структури. Рішення, які пропонує платформа Java EE, корисні, а часом просто необхідні окремим розробникам та невеликим організаціям.

Розвиток Java EE

Java EE розвивається за процесом Java Community Process (JCP), сформованим 1998 року. Він дозволяє зацікавленим особам брати участь у формуванні майбутніх версій специфікацій платформ Java. Основу цього процесу складають JSR (Java Specification Request — запит на специфікацію Java), формальні документи, що описують специфікації та технології, які пропонується додати до Java-платформи. Подібні запити складаються членами спільноти - простими розробниками та компаніями. До останніх відносяться Oracle, Red Hat, IBM, Apache і багато інших. Тобто. хлопці пропонують на розгляд нові фічі та плюшки, які вони хотіли б включити до Java. А потім проводять голосування, на підставі якого ухвалюється рішення, що включити до наступної версії. Історія версій Java EE виглядає так:

• J2EE 1.2 (Грудень 1999)
• J2EE 1.3 (Вересень 2001)
• J2EE 1.4 (Листопад 2003)
• Java EE 5 (Тдорівнюєь 2006)
• Java EE 6 (Грудень 2009)
• Java EE 7 (Май)
• Java EE 8 (Серпень 2017)
• Jakarta EE 8 (Вересень 2019)

У 2017 році відбулася нова віха у розвитку платформи: Oracle передав контроль над розвитком Java EE організації Eclipse Foundation. А у квітні 2018 року Java EE перейменували на Jakarta EE, яка повністю сумісна з Java EE 8.

Архітектура Java EE додатків

Невеликий вступ. Щоб полегшити сприйняття, поговоримо про пристрій Java EE додатків і деякі терміни, які ми будемо вживати далі. У Java EE додатків є структура, яка має дві ключові якості:

• по-перше, багаторівневість. Java EE програми - багаторівневі, і про це ми ще поговоримо докладніше;
• по-друге, вкладеність. Є Java EE сервер (або сервер додатків), усередині нього розміщуються контейнери компонентів. У цих контейнерах розміщуються компоненти (бінго!).

Щоб пояснити архітектуру Java EE додатків, спочатку поговоримо про рівні. Які рівні? Які технології Java EE використовуються на різних рівнях? Далі ми обговоримо, як між собою пов'язані сервери додатків, контейнери компонентів та самі компоненти. Але врахуйте, що все це — погляди під різними кутами на те саме, і черговість тут не така важлива.

Рівні додатків

Багаторівневі програми — це програми, які розділені за функціональним принципом на ізольовані модулі (рівні, шари). Зазвичай (у тому числі в контексті Java EE розробки) корпоративні програми ділять на три рівні:

• клієнтська;
• середній рівень;
• рівень доступу до даних.

1. Клієнтський рівень є деяким додатком, який запитує дані у Java EE сервера (середнього рівня). Сервер, у свою чергу, обробляє запит клієнта та повертає йому відповідь. Клієнтським додатком може бути браузер, окрема програма (мобільна або десктопна) або інші серверні програми без графічного інтерфейсу.

2. Середній рівень поділяється, у свою чергу, на web-рівень та рівень бізнес-логіки.

   1. Web-рівень складається з деяких компонентів, які забезпечують взаємодію між клієнтами та рівнем бізнес-логіки.

      На web-рівні використовуються такі технології Java EE:

      • JavaServer Faces technology (JSF);
      • Java Server Pages (JSP);
      • Expression Language (EL);
      • Servlets;
      • Contexts and Dependency Injection for Java EE (CDI).

   2. Рівень бізнес-логіки складається з компонентів, у яких реалізована вся бізнес-логіка програми. Бізнес-логіка - це код, який забезпечує функціональність, що покриває потреби певної конкретної сфери бізнесу (фінансова індустрія, банківська справа, електронна комерція). Цей рівень вважатимуться ядром всієї системи.

      Технології, які задіяні на цьому рівні:

      • Enterprise JavaBeans (EJB);
      • JAX-RS RESTful web services;
      • Java Persistence API entities;
      • Java Message Service.

3. Рівень доступу до даних. Цей рівень іноді називають рівнем корпоративних інформаційних систем (Enterprise Information Systems, скорочено EIS). EIS складається з різних серверів баз даних, ERP (Enterprise Resource Planning) систем планування ресурсів підприємства та інших джерел даних. До цього рівня за даними звертається рівень бізнес-логіки.

   На цьому рівні можна зустріти такі технології, як:

   • Java Database Connectivity API (JDBC);
   • Java Persistence API;
   • Java EE Connector Architecture;
   • Java Transaction API (JTA).

Сервера додатків, контейнери, компоненти

Погляньмо на визначення Java EE із Вікіпедії. Java EE - набір специфікацій та відповідної документації для мови Java, що описує архітектуру серверної платформи для завдань середніх та великих підприємств. Щоб краще зрозуміти, що означає в даному контексті набір специфікацій, проведемо аналогію з Java-інтерфейсом. Сам собою Java-інтерфейс позбавлений функціональності. Він просто визначає деякий контракт, за яким реалізується деяка функціональність. А ось реалізують інтерфейс вже інші класи. Причому в одного інтерфейсу допустимі кілька реалізацій, кожна з яких може відрізнятися один від одного деякими деталями. Зі специфікацією все так само. Гола Java EE – це просто набір специфікацій. Дані специфікації реалізують різні Java EE сервери. Java EE сервер - це серверна програма, яке реалізує API-інтерфейси платформи Java EE та надає стандартні служби Java EE. Сервери Java EE іноді називають серверами програм. Дані сервера можуть містити компоненти програми, кожен з яких відповідає своєму рівню в багаторівневій ієрархії. Сервер Java EE надає цим компонентам різні сервіси у вигляді контейнера. Контейнери – це інтерфейс між розміщеними на них компонентами та низькорівневими платформо-незалежними функціональними можливостями, що підтримують компонент. Контейнери надають розміщеним ними компонентам певні служби. Наприклад, управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує Сервери Java EE іноді називають серверами програм. Дані сервера можуть містити компоненти програми, кожен з яких відповідає своєму рівню в багаторівневій ієрархії. Сервер Java EE надає цим компонентам різні сервіси у вигляді контейнера. Контейнери – це інтерфейс між розміщеними на них компонентами та низькорівневими платформо-незалежними функціональними можливостями, що підтримують компонент. Контейнери надають розміщеним ними компонентам певні служби. Наприклад, управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує Сервери Java EE іноді називають серверами програм. Дані сервера можуть містити компоненти програми, кожен з яких відповідає своєму рівню в багаторівневій ієрархії. Сервер Java EE надає цим компонентам різні сервіси у вигляді контейнера. Контейнери – це інтерфейс між розміщеними на них компонентами та низькорівневими платформо-незалежними функціональними можливостями, що підтримують компонент. Контейнери надають розміщеним ними компонентам певні служби. Наприклад, управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує Сервер Java EE надає цим компонентам різні сервіси у вигляді контейнера. Контейнери – це інтерфейс між розміщеними на них компонентами та низькорівневими платформо-незалежними функціональними можливостями, що підтримують компонент. Контейнери надають розміщеним ними компонентам певні служби. Наприклад, управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує Сервер Java EE надає цим компонентам різні сервіси у вигляді контейнера. Контейнери – це інтерфейс між розміщеними на них компонентами та низькорівневими платформо-незалежними функціональними можливостями, що підтримують компонент. Контейнери надають розміщеним ними компонентам певні служби. Наприклад, управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існує управління життєвим циклом розробки, використання залежності, паралельний доступ тощо. буд. Контейнери приховують технічну складність і підвищують мобільність. У Java EE існуєчотири різні типи контейнерів:

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

2. Контейнер клієнтської програми (ACC) включає набір Java-класів, бібліотек та інших файлів, необхідних для реалізації у програмах Java SE таких можливостей, як впровадження, управління безпекою та служба іменування.

3. Веб-контейнер надає базові служби для керування та виконання веб-компонентів (сервлетів, компонентів EJB Lite, сторінок JSP, фільтрів, слухачів, сторінок JSF та веб-служб). Він відповідає за створення екземплярів, ініціалізацію та виклик сервлетів, а також підтримку протоколів HTTP та HTTPS. Цей контейнер використовується для подачі веб-сторінок до клієнт-браузерів.

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

Також у Java EE виділяють чотири типи компонентів , які має підтримувати реалізація Java EE специфікації:

1. Аплети — це програми з графічного інтерфейсу користувача (GUI), що виконуються в браузері. Вони задіяють насичений інтерфейс Swing API для виробництва потужних інтерфейсів користувача.

2. Програмами називаються програми, що виконуються на клієнтській стороні. Як правило, вони відносяться до графічного інтерфейсу користувача (GUI) і застосовуються для пакетної обробки.

3. Веб-програми (складаються з сервлетів та їх фільтрів, слухачів веб-подій, сторінок JSP та JSF) – виконуються у веб-контейнері та відповідають на запити HTTP від ​​веб-клієнтів. Сервлети також підтримують кінцеві точки веб-служб SOAP та RESTful.

4. Корпоративні програми (створені за допомогою технології Enterprise Java Beans, служби повідомлень Java Message Service, інтерфейсу Java API для транзакцій, асинхронних дзвінків, служби часу) виконуються у контейнері EJB. Компоненти EJB, що керуються контейнером, служать для обробки транзакційної бізнес-логіки. Доступ до них може бути як локальним, так і віддаленим за протоколом RMI (або HTTP для веб-служб SOAP та RESTful).

На діаграмі нижче представлена ​​типова архітектура Java EE програми:

Технології

Отже, із архітектурою розібралися. Загальна структура має бути зрозумілою. У процесі опису компонентів архітектури ми торкнулися деяких технологій Java EE, таких як EJB, JSP та ін. Давайте ближче подивимося на них. У таблиці нижче наведено технології, які використовуються в основному на клієнтському рівні: У таблиці нижче наведено технології, що використовуються на рівні бізнес-логіки: У таблиці нижче наведено технології, які використовуються на рівні доступу до даних:

Java EE vs Spring

Конкурентним Java EE вважається Spring Framework. Якщо подивитись розвиток двох даних платформ, виходить цікава картина. Перші версії Java EE були створені за участю IBM. Вони вийшли крутими, але неповороткими, важкими, незручними у використанні. Розробники плювалися через необхідність підтримувати велику кількість конфігураційних файлів та інших причин, що ускладнюють розробку. У той самий час світ з'явився Spring IoC. Це була маленька, красива та приємна у зверненні бібліотека. У ній також використовувався конфігураційний файл, але на відміну Java EE, він був один. Простота Spring призвела до того, що практично всі почали використовувати цей фреймворк у своїх проектах. А далі Spring і Java EE почали свій шлях до того самого, але з різних кінців. Компанія Pivotal Software, розробник Spring, стали випускати проект за проектом, щоб покрити всі можливі та неможливі потреби Java-розробників. Поступово те, що раніше називалося Spring, спочатку стало одним із проектів, а потім і зовсім злилося з кількома іншими проектами Spring Core. Все це призвело до неминучого ускладнення Spring у порівнянні з тим, яким він був спочатку. Згодом стежити за всім клубком залежностей спрингу стало дуже складно, і виникла потреба в окремій бібліотеці, яка стала б завантажувати і запускати все сама (зараз десь икнув так улюблений Spring Boot). Все це призвело до неминучого ускладнення Spring у порівнянні з тим, яким він був спочатку. Згодом стежити за всім клубком залежностей спрингу стало дуже складно, і виникла потреба в окремій бібліотеці, яка стала б завантажувати і запускати все сама (зараз десь икнув так улюблений Spring Boot). Все це призвело до неминучого ускладнення Spring у порівнянні з тим, яким він був спочатку. Згодом стежити за всім клубком залежностей спрингу стало дуже складно, і виникла потреба в окремій бібліотеці, яка стала б завантажувати і запускати все сама (зараз десь икнув так улюблений Spring Boot). Весь цей час JCP працював над одним — досягти максимального спрощення всього, що тільки можна всередині Java EE. У результаті в сучасному EJB для опису біна достатньо вказати одну інструкцію над класом, що надає розробнику доступ до всієї потужності технології Enterprise Java Beans. І подібні спрощення торкнулися кожної специфікації всередині Java EE. У результаті за функціоналом Spring і Java EE приблизно поділяють паритет. Де щось краще, де щось гірше, але якщо дивитися глобально, великих відмінностей немає. Те саме стосується складності роботи. І Spring, і Java EE є чудовими інструментами. Мабуть, найкращими з того, що є зараз, для побудови корпоративних мережевих додатків на мові Java. Однак, Java EE може працювати в загальному випадку тільки в рамках Enterprise Application Server (Tomcat таким не є), а додаток на Spring стеку може працювати на чому завгодно (на тому ж Tomcat), і навіть взагалі без сервера (оскільки запустить його в собі самостійно). Це робить Spring ідеальним інструментом для розробки невеликих програм із GUI на Front-end або для мікросервісної архітектури. Але відмова від залежності від серверів додатків негативно позначився на масштабованості Spring-додатків. А Java EE добре підходить для реалізації масштабованого монолітного кластерного додатку. На ринку праці на даний момент найбільш популярні розробники, знайомі зі Spring Framework. Так склалося історично: у ті часи, коли Java EE була надмірно ускладнена, Spring "набрав клієнтську базу". Проте однозначної відповіді на питання що вчити Spring або Java EE, немає. Новачку можна дати наступну пораду. Познайомитись (хоча б поверхово) з обома платформами. Написати невеликий домашній проект і на Java EE і Spring. А далі заглиблюватися у той фреймворк, який знадобиться на роботі. У результаті, перемикатися між Spring і Java EE не складе величезної праці.

Підсумки

Масштабну тему, звичайно, однією статтею не охопити! Після тонни нових термінів, напевно, хочеться “прикласти” ці знання до життєвого прикладу. Тому ми продовжимо вивчати Java EE: уроки практичні, налаштування локального оточення для Java EE розробки, ви знайдете в наступній статті.