Нужна помощь в определении/понимании стека Java EE

Эта диаграмма НЕ является стеком Java EE.

Это может быть полезно (или нет:):

• Java EE — это управляемая система времени выполнения. (У LAMP таких проблем нет.)

• Java EE использует общую архитектуру контейнера компонентов (LAMP не определяет явный API-интерфейс контейнера компонентов)

• Серверы приложений, такие как JBoss, Glassfish и т. д., предоставляют контейнер Java EE. (Tomcat не поддерживает полный стек Java EE. Tomcat и Jetty предоставляют только веб-контейнер (или веб-профиль в соответствии с последними спецификациями.))

• Обратите внимание, что веб-контейнеры Java EE (сервлеты) намного проще, чем полноценный стек Java EE, но основаны на том же архитектурном подходе.

• Веб-компоненты Java EE — это (по сути) сервлеты и фильтры. Различные фреймворки более высокого порядка (такие как Faces) построены поверх этой архитектуры. Веб-контейнер Java EE относительно прост и очень эффективен. Это ближе всего к LAMP.

• Корпоративные компоненты Java EE (поддерживаемые серверами приложений Java EE, такими как GlassFish) представляют собой различные разновидности компонентов без сохранения состояния, с сохранением состояния и постоянных компонентов (известных как «бины» в мире Java).

• Hibernate является ORM и является избыточным в контексте полной версии Java EE (например, EntityBeans). Как правило, JPA используется с системами Web-Container "Java EE" для подключения к серверной СУБД, совместимой с JDBC. Оракл, MySQL, что угодно.

• вы (и/или какая-то сторонняя библиотека) предоставляете компоненты.

• Управляемая среда выполнения в первую очередь связана с заботой об "ортогональных" "корпоративных" "проблемах", таких как целостность транзакций, и предполагается, что вы, автор компонентов/приложений, должны быть сосредоточены на "бизнес-логике".

• Java EE управляет ссылками, границами транзакций, связью и жизненным циклом ваших компонентов.

• Ссылки: использование семантических ссылок, просматриваемых во время выполнения с помощью механизма пространства имен, также известного как JNDI и RMI; и внедрение зависимостей через декларативные дескрипторы развертывания.

• Жизненный цикл: ваши компоненты будут иметь правильные этапы запуска, работы и завершения работы. Вы можете подключиться к этим событиям LC и принять в них участие, если это необходимо (обычно не требуется). Этот формализованный LC позволяет распространять и масштабировать архитектуру.

• Возможность подключения: в широком смысле относится к входящим (клиенты) и внутренним (EIS) точкам интеграции. Для клиентов у вас есть web/RMI/JMS и т. д. Это дает вам семантику sync req/rep и асинхронный запуск и забвение. Для серверной части (в целом) JCA определяет соединители с другими системами. JPA — это специализация JCA (теоретически, а не на практике), которая специально обращается к EIS базы данных с пользовательским API JDBC.

• Транзакции: декларативный означает применение семантики транзакций к определенным методам компонента. Это можно сделать во время разработки (через аннотации) или во время развертывания (через XML).

Пакеты развертывания

Системы Java EE обычно упаковываются как WAR (только для Интернета) или EAR (для полного стека).

Дескрипторы развертывания

Последние спецификации Java EE отдают предпочтение операциям без конфигурации с разумными значениями по умолчанию (или тривиальными сопоставлениями). Но важно, чтобы вы осознали, что это такое, и в какой-то момент любое серьезное приложение Java EE потребует обработки этих артефактов на каком-то уровне. (Это намного проще для web.xml, так что не волнуйтесь.) Это ключевой аспект архитектуры. Поймите это и все остальное очень ясно.

Java EE использует косвенность, чтобы творить чудеса. Это проблема, которая решается здесь:

У нас есть компоненты, написанные какой-то третьей стороной (некоторое время назад), и нам нужно использовать их в нашем приложении. Дескрипторы развертывания позволяют отображать семантику вашего приложения, например. имя компонента или его семантика транзакций к общей семантике компонентов. Например, вы можете представить «Acme-Logger» как «My-Very-Own-Logger». Это достигается путем сопоставления желаемого имени среды с классом компонента. (Исходный компонент мог иметь аннотацию, объявляющую его общее имя просто «the-logger»).

Весна, по сути, наступила из-за серьезной боли, связанной с созданием и обслуживанием этих дескрипторов отображения. Опять же, Spring — это альтернативный подход к системам на основе контейнеров.

Контейнеры

Теоретически у вас должна быть возможность подключить целый контейнер к совместимому серверу, но общая идея заключается в том, что вы пишете свои компоненты для универсального контейнера, например. контейнер Java EE. В любом случае, как вы можете себе представить, поставщики серверов приложений Java EE не слишком стремились иметь подключаемый API-интерфейс контейнера для стека, поскольку это сделало бы их продукт полноценным товаром.

Весна

Spring на самом деле является противоположностью Java EE. Это (или была) легкая контейнерная система для устранения болевых точек J2EE (что было совершенно неразумно без эффективного инструментария, учитывая сложную архитектуру и процедуру развертывания). По сути, внешний интерфейс Servlet и контейнер Spring являются альтернативой полноценному стеку Java EE. Тем не менее, они могут сосуществовать.

Мавен

Maven — это инструмент сборки. Есть и муравейник. Или вы можете прыгнуть на Gradle. Существуют архетипы Maven, позволяющие без особых усилий приступить к работе с базовым проектом Java EE.

Предложение:

Начните с (и придерживайтесь) подмножества веб-контейнеров. Jetty или Tomcat — прекрасный выбор для контейнера/сервера.

Познакомьтесь с WEB-INF/ и web.xml. Напишите простое расширение HTTPServlet и поэкспериментируйте с функциями файла web.xml. Попробуйте настроить фильтр или привязать некоторые параметры к контексту веб-приложения. Овладейте этими основами. Все остальное строится поверх них. Все.

В сервлете изучите предоставленный API. Узнайте разницу между контекстами приложения, сеанса и запроса. Ключевой вопрос в веб-уровне. Научитесь перенаправлять запросы. Получите заголовки http и т. д. Все остальное построено на них. Овладейте этими основами.

Допустим, на данный момент у вас есть веб-приложение HelloWorld. Следующим шагом попробуйте JPA и добавьте постоянство в свой проект. Здесь вы можете попробовать учебный пример Spring/Hibernate/Tomcat. Spring настроит контейнер EE, отличный от Java, для ваших бизнес-компонентов (классов). Hibernate позаботится о сохранении ваших данных. При этом появляется пара новых артефактов. XML-файлы, связанные с Spring, и сопоставления JPA/Hibernate. Узнайте об этом и о том, что это такое.

Ты почти сделал. Наконец, давайте обратимся к проблемам представления или представления. Вот где Java (imo) отстой, поскольку он слишком многословен, и этот уровень связан с бессмысленным повторением: поместить виджет сюда, поместить виджет туда и т. д.

В самом простом (и готовом) виде у вас есть базовый HTTPServlet и возможность отправлять обратно все, что вам хочется. Вы можете написать свой html в своем коде (очень плохая идея), или использовать шаблонный подход (Velocity, FreeMarker), или перейти к специализированным компонентам для представления: JSP, Faces и т. д. Существуют буквально десятки фреймворков (и подходы) для уровня представления.

Надеюсь, это помогло.

Да, диаграмма, которую вы разместили, пугает, но вам не нужно использовать все это. Это не все необходимое.

Если вы новичок, сохраняйте простоту и наращивайте.

Вот самое дно, обязательные предметы для начала:

1. Сервлеты и JSP. Это означает развертывание на движке сервлета/JSP, таком как Tomcat или Jetty. Сервлеты — это прослушиватели HTTP, которые обрабатывают входящие запросы, сотрудничают с внутренними классами для их выполнения и направляют ответы в соответствующее следующее представление.
2. JSP — это шаблонное решение для создания HTML. Вы должны писать их только с использованием JSTL, стандартной библиотеки тегов JSP. Никаких скриптлетов.
3. HTML, CSS и JavaScript для пользовательского интерфейса. Они нужны вам для веб-интерфейсов.
4. JDBC для доступа к реляционным базам данных.

Вот и все. Только с ними можно пройти очень долгий путь.

Я люблю весну, но в первый раз ее трудно проглотить. Сделайте сайт или два без него. Вы будете лучше понимать вещи и больше ценить то, что Spring делает для вас.

Вам не нужен JSF. Я бы сказал, что это технология в упадке. Единственное приложение JSF/Faces, которое я видел лично, абсолютно отстойное. Вы можете рассчитать загрузку страницы с помощью солнечных часов. Я не вижу в нем больших преимуществ, несмотря на то, что он рекламируется как стандарт Java EE. Собираетесь ли вы запускать JSF в мобильном интерфейсе? Я так не думаю.

Пользовательские интерфейсы написаны с использованием HTML, CSS и JavaScript, которые взаимодействуют со службами на серверной части. Эти сервисы могут быть REST-ful сервлетами.

Hibernate — это технология объектно-реляционного отображения. Если у вас нет объектной модели, вам не нужен Hibernate. Если у вас есть простые отношения один к одному между объектами и таблицами, вам не нужен Hibernate. Если вам нравятся хранимые процедуры в качестве интерфейса к вашей реляционной базе данных, вам не нужен Hibernate. Если вы не против написать небольшой SQL и отобразить результаты, вам не нужен Hibernate. То же самое для JPA — Hibernate — это один из способов реализации JPA, который многое взял от Hibernate.

Начните с них и наращивайте. Если вы попытаетесь выучить все вещи, которые вы процитировали, сразу, вы никогда ничего не добьетесь.