Энтони Гонсалвес - Изучаем Java EE 7

Рис. 1.4.История J2ЕЕ/Java EE

Начиная с J2EE 1.3, разработкой спецификаций занималась группа Java Community Process (JCP) в рамках запроса JSR 58. Поддержка компонентов-сущностей стала обязательной, а в компонентах EJB появились дескрипторы развертывания XML для хранения метаданных (которые были сериализованы в отдельном файле в EJB 1.0). В этой версии была решена проблема издержек, связанных с передачей аргументов по значению при использовании удаленных интерфейсов. Для ее устранения появились локальные интерфейсы и возможность передачи аргументов по ссылке. Была разработана архитектура JCA (J2EE Connector Architecture), позволившая связать Java EE с корпоративной информационной системой (EIS).

CORBA была разработана в 1988 году именно потому, что корпоративные системы становились распределенными (примеры таких систем: Tuxedo и CICS). Затем последовали EJB и J2EE, которые создавались на десять лет позже, но также предназначались для работы с распределенными системами. К моменту разработки J2EE CORBA имела основательную поддержку и являлась промышленным ПО, однако компании нашли более простые и гибкие способы соединения распределенных систем, такие как веб-службы SOAP или REST. Поэтому для большинства корпоративных систем исчезла необходимость применения CORBA.

В 2003 году в J2EE 1.4 (запрос на спецификацию JSR 151) входило 20 спецификаций и добавилась поддержка веб-служб. Спецификация EJB 2.1 разрешала вызов компонент-сеансов EJB по протоколам SOAP/HTTP. Была создана служба времени для вызова компонентов в указанное время или с заданным интервалом. Эта версия оптимизировала поддержку сборки и развертывания приложений. И хотя сторонники J2EE предсказывали ей большое будущее, не весь обещанный функционал был реализован. Системы, созданные с ее применением, были очень сложными, а на их разработку тратилось слишком много времени даже при самых тривиальных требованиях пользователя. J2EE считалась тяжеловесной компонентной моделью, сложной для тестирования, развертывания и запуска. Как раз в то время появились фреймворки Struts, Spring и Hibernate, предложившие новый способ разработки корпоративного приложения.

К счастью, во втором квартале 2006 года вышла значительно улучшенная Java EE 5 (запрос на спецификацию JSR 244). Опираясь на примеры свободных фреймворков, она возродила модель программирования POJO. Метаданные могли определяться аннотациями, а дескрипторы развертывания XML стали опциональными. С точки зрения разработчика, создание EJB 3 и нового интерфейса JPA было настоящим качественным скачком, а не рядовым эволюционным изменением. В качестве стандартного фреймворка был представлен JavaServer Faces (JSF), а в качестве API для работы с SOAP-службами стал использоваться JAX-WS 2.0, заменивший JAX-RPC.

В 2009 году появилась Java EE 6 (запрос на спецификацию JSR 316), продолжившая традицию простоты разработки. Она включала в себя концепции аннотаций, программирования POJO, а также механизма конфигурации путем исключения в масштабах всей платформы, в том числе на веб-уровне. Ее отличал широкий спектр инноваций, например принципиально новый интерфейс JAX-RS 1.1, валидация компонентов 1.0, контекст и внедрение зависимости (CDI 1.0). Некоторые из ранее разработанных API (например, EJB 3.1) были упрощены, другие, наоборот, доработаны (JPA 2.0 или служба времени EJB). Однако основными новшествами Java EE 6 стали портируемость (например, с помощью стандартизации глобального именования JNDI), избавление от некоторых спецификаций (с помощью отсечения) и создание подсистем платформы с использованием профилей.

Сегодня Java EE 7 предлагает много новых спецификаций (пакетная обработка, веб-сокеты, обработка JSON), а также совершенствует существующие. Java EE 7 также улучшает интеграцию между технологиями, задействуя контексты и внедрения зависимостей (CDI) в большинстве спецификаций. В данной книге я хочу продемонстрировать эти улучшения, а также показать, насколько проще и полнее стала платформа Java Enterprise Edition.

Впервые версия Java EE была выпущена в 1999 году, и с тех пор в каждом релизе добавлялись новые спецификации (см. рис. 1.4). Постепенно это стало проблемой. Некоторые функции поддерживались не полностью или не очень широко применялись, так как были технологически устаревшими, либо им находились достойные альтернативы. Поэтому экспертная группа внесла предложение об удалении некоторого функционала методом отсечения. Процесс отсечения заключается в составлении списка функций, подлежащих возможному удалению в следующем релизе Java EE. Обратите внимание, что ни одна из функций, предложенных к удалению, не убирается из текущей версии, но может быть удалена в следующей. Java EE 6 предложила удалить следующие спецификации и функции, и в Java EE 7 их уже не было.

• Компоненты-сущности EJB 2.xCMP (входили в запрос на спецификацию JSR 318). Сложная и тяжеловесная модель персистентности, состоящая из компонентов-сущностей EJB2.х, была заменена интерфейсом JPA.

• Интерфейс JAX-RPC (запрос на спецификацию JSR 101). Это была первая попытка моделирования веб-служб SOAP в качестве вызовов удаленных процедур (RPC). Ему на замену пришел гораздо более простой в использовании и надежный интерфейс JAX-WS.

• Интерфейс JAXR (запрос на спецификацию JSR 93). JAXR — интерфейс, посвященный обмену данными с реестрами стандарта UDDI. Поскольку этот стандарт недостаточно широко используется, интерфейс JAXR исключен из Java EE и развивается в рамках отдельного запроса JSR.

• Развертывание приложений Java EE (запрос JSR 88). JSR 88 — спецификация, которую разработчики инструментов могут использовать для развертывания на серверах приложений. Этот интерфейс не получил большой поддержки разработчиков, поэтому он также исключается из Java EE 7 и будет развиваться в рамках отдельной спецификации.

Спецификация Java EE 7 определяется запросом JSR 342 и объединяет в себе 31 спецификацию. Сервер приложений, призванный обеспечить совместимость с Java EE 7, должен реализовывать все эти спецификации. Они перечислены в табл. 1.2–1.6, где сгруппированы по технологическим предметным областям, с указанием версии и номера запроса JSR.

В области веб-служб (см. табл. 1.3) службы SOAP не дорабатывались, так как никакие спецификации не обновлялись (см. главу 14).