Введение в Java EE

Сегодня поговорим о том, что это такое — Java EE: из чего состоит, Howовы особенности архитектуры Java EE приложений, и приведем описания различных технологий данной платформы. Тема обширная сама по себе, но на азах мы не остановимся. В конце проведем небольшое сравнение Java EE со Spring Framework и ответим на вопрос: “что лучше учить” (спойлер: конечно же, учить нужно всё =) ) Начнем с основ.

Java EE — что это?

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

Развитие Java EE

Java EE развивается по процессу Java Community Process (JCP), сформированному в 1998 году. Он позволяет заинтересованным лицам участвовать в формировании будущих версий спецификаций платформ языка Java. Основу данного процесса составляют JSR (Java Specification Request — request на спецификацию Java), формальные documentы, описывающие спецификации и технологии, которые предлагается добавить к Java-платформе. Подобные requestы составляются членами сообщества — простыми разработчиками и компаниями. К числу последних относятся 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, которая fully совместима с Java EE 8.

Архитектура Java EE приложений

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

• во-первых, многоуровневость. Java EE applications — многоуровневые, и об этом мы еще поговорим подробнее;
• во-вторых, вложенность. Есть Java EE server (or server приложений), внутри него располагаются контейнеры компонентов. В данных контейнерах размещаются (бинго!) компоненты.

Whatбы объяснить архитектуру Java EE приложений, для начала поговорим об уровнях. Какие бывают уровни? Какие Java EE технологии используются на различных уровнях? Далее мы обсудим, How между собой связаны serverа приложений, контейнеры компонентов и сами компоненты. Но учтите, что все это — взгляды под различными углами на одно и то же, и очередность тут не так важна.

Уровни приложений

Многоуровневые applications — это applications, которые разделены по функциональному принципу на изолированные модули (уровни, слои). Обычно (в том числе в контексте Java EE разработки) корпоративные applications делят на три уровня:

• клиентский;
• средний уровень;
• уровень доступа к данным.

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

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. Уровень бизнес-логики состоит из компонент, в которых реализована вся бизнес-логика applications. Бизнес-логика — это code, который обеспечивает функциональность, покрывающую нужды некоторой конкретной бизнес сферы (финансовая индустрия, банковское дело, электронная коммерция). Данный уровень можно считать ядром всей системы.

      Технологии, которые задействованы на данном уровне:

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

3. Уровень доступа к данным. Данный уровень иногда называют уровнем корпоративных информационных систем (Enterprise Information Systems, сокращенно —EIS). EIS состоит из различных serverов баз данных, ERP (англ. Enterprise Resource Planning) систем планирования ресурсов предприятия и прочих источников данных. К этому уровню за данными обращается уровень бизнес-логики.

   В данном уровне можно встретить такие технологии, How:

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

Сервера приложений, контейнеры, компоненты

Взглянем на определение Java EE из Википедии. Java EE — набор спецификаций и соответствующей documentации для языка Java, описывающий архитектуру serverной платформы для задач средних и крупных предприятий. Whatбы лучше понять, что означает в данном контексте “набор спецификаций”, проведем аналогию с Java-интерфейсом. Сам по себе Java-интерфейс лишен функциональности. Он просто определяет некоторый контракт, согласно которому реализуется некоторая функциональность. А вот реализуют интерфейс уже другие классы. Причем у одного интерфейса допустимы несколько реализаций, каждая из которых может друг от друга отличаться некоторыми деталями. Со спецификацией все точно так же. Голая Java EE — это просто набор спецификаций. Данные спецификации реализуют различные Java EE serverа. Java EE server — это serverное приложение, которое реализует API-интерфейсы платформы Java EE и предоставляет стандартные службы Java EE. Серверы Java EE иногда называют serverами приложений. Данные serverа могут содержать в себе компоненты applications, каждый из которых соответствует своему уровню в многоуровневой иерархии. Сервер Java EE предоставляет этим компонентам различные сервисы в форме контейнера. Контейнеры — это интерфейс между размещенными на них компонентами и низкоуровневыми платформо-независимыми функциональными возможностями, поддерживающими компонент. Контейнеры предоставляют размещенным на них компонентам определенные службы. Например, управление жизненным циклом разработки, внедрение зависимости, параллельный доступ и т. д. Контейнеры скрывают техническую сложность и повышают мобильность. В Java EE существует четыре различные типа контейнеров:

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

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

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

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

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

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

2. Приложениями называются программы, выполняемые на клиентской стороне. Как правило, они относятся к графическому пользовательскому интерфейсу (GUI) и применяются для пакетной обработки.

3. Веб-applications (состоят из сервлетов и их фильтров, слушателей веб-событий, страниц JSP и JSF) — выполняются в веб-контейнере и отвечают на requestы HTTP от веб-клиентов. Сервлеты также поддерживают конечные точки веб-служб SOAP и RESTful.

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

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

Технологии

Итак, с архитектурой разобрались. Общая структура должна быть ясна. В процессе описания компонентов архитектуры мы затронули некоторые технологии Java EE, такие How EJB, JSP и пр. Давайте поближе посмотрим на них. В таблице ниже приведены технологии, которые используются в основном на клиентском уровне: В таблице ниже приведены технологии используемые на уровне бизнес-логики: В таблице ниже приведены технологии, используемые на уровне доступа к данным:

Java EE vs Spring

Конкурентном Java EE считается Spring Framework. Если взглянуть на развитие двух данных платформ, выходит интересная картина. Первые версии Java EE были созданы при участии IBM. Они вышли крутыми, но неповоротливыми, тяжеловесными, неудобными в использовании. Разработчики плевались из-за необходимости поддерживать большое количество конфигурационных файлов и из-за прочих причин, усложняющих разработку. В то же время на свет появился Spring IoC. Это была маленькая, красивая и приятная в обращении библиотека. В ней также использовался конфигурационный файл, но в отличии от Java EE, он был один. Простота Spring привела к тому, что практически все стали использовать данный фреймворк в своих проектах. А далее Spring и Java EE начали свой way to одному и тому же, но с разных концов. Компания Pivotal Software, разработчик Spring, стали выпускать проект за проектом, чтобы покрыть все возможные и невозможные потребности Java-разработчиков. Постепенно то, что раньше называлось Spring, сначала стало одним из проектов, а потом и вовсе слилось с несколькими другими проектами в Spring Core. Все это привело к неминуемому усложнению Spring по сравнению с тем, Howим он был изначально. Со временем следить за всем клубком зависимостей спринга стало уж совсем сложно, и возникла потребность в отдельной библиотеке, которая стала бы загружать и запускать все сама (сейчас где-то икнул так горячо любимый Spring Boot). Все это время JCP работал над одним — добиться максимального упрощения всего, что только можно внутри Java EE. В итоге в современном EJB для описания бина достаточно указать одну аннотацию над классом, что предоставляет разработчику доступ ко всей мощи технологии Enterprise Java Beans. И подобные упрощения затронули каждую спецификацию внутри Java EE. В итоге по функционалу Spring и Java EE примерно разделяют паритет. Где-то что-то лучше, где-то что-то хуже, но если смотреть глобально, больших различий нет. То же самое касается сложности работы. И Spring, и Java EE являются превосходными инструментами. Пожалуй, лучшими из того, что сейчас есть, для построения корпоративных сетевых приложений на языке Java. Однако, Java EE может работать в общем случае только в рамках Enterprise Application Server’a (Tomcat таковым не является), а приложение на Spring стеке может работать на чем угодно (на том же Tomcat), и даже вообще без serverа (так How запустит его внутри себя самостоятельно). Это делает Spring идеальным инструментом для разработки небольших приложений с GUI на Front-end or для микросервисной архитектуры. Но отказ от зависимости от serverов приложений отрицательно сказался на масштабируемости Spring-приложений. А Java EE хорошо подходит для реализации масштабируемого монолитного кластерного applications. На рынке труда на текущий момент более востребованы разработчики, знакомые со Spring Framework. Так сложилось исторически: в те времена, когда Java EE была излишне усложнена, Spring "набрал клиентскую базу". И тем не менее, однозначного ответа на вопрос что учить Spring or Java EE, нет. Новичку можно дать следующий совет. Познакомиться (хотя бы поверхностно) с обеими платформами. Написать небольшой домашний проект и на Java EE и на Spring. А далее углубляться в тот фреймворк, который потребуется на работе. В итоге, переключаться между Spring и Java EE не составит большого труда.

Итоги

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