В самом начале развития Java, если вы занимались корпоративной или веб-разработкой, вы должны были подчиняться законам проприетарного мира, создавая свои собственные фреймворки, либо ограничивать себя проприетарным коммерческим фреймворком. Затем настало время свободных фреймворков, которые не всегда основываются на открытых стандартах. Вы можете использовать свободные фреймворки и ограничиваться одной-единственной реализацией либо применять такие открытые фреймворки, которые подчиняются стандартам, чтобы приложение было портируемым. Java EE предусматривает открытые стандарты, реализуемые несколькими коммерческими (WebLogic, Websphere, MQSeries и др.) или свободными (GlassFish, Jboss, Hibernate, Open JPA, Jersey и т. д.) фреймворками для работы с транзакциями, безопасностью, хранящими состояние компонентами, хранимостью объектов и т. д. Сегодня ваше приложение может быть развернуто на любом совместимом сервере приложений с очень малым количеством изменений.
JCP
Java Communication Process — открытая организация, созданная в 1998 году компанией Sun Microsystems. Одно из направлений работы JCP — определение будущих версий и функционала платформы Java. Когда определяется необходимость в стандартизации существующего компонента или интерфейса, ее инициатор (руководитель спецификации) создает запрос на спецификацию Java (JSR) и формирует группу экспертов. Такие группы, состоящие из представителей компаний, организаций, университетов или частных лиц, ответственны за разработку запроса на спецификацию (JSR) и по итогу представляют:
• одну или несколько спецификаций, объясняющих детали и определяющих основные понятия запроса на спецификацию Java (JSR);
• базовую реализацию (RI), которая является фактической реализацией спецификации;
• пакет проверки совместимости (известный также как пакет проверки технологической совместимости, или TCK), представляющий собой набор тестов, которые должна пройти каждая реализация для подтверждения соответствия спецификации.
После одобрения исполнительным комитетом (EC) спецификация выпускается в Java-сообщество для внедрения.
Портируемость
С самого создания целью Java EE было обеспечить разработку приложения и его развертывание на любом сервере приложений без изменения кода или конфигурационных файлов. Это никогда не было так просто, как казалось. Спецификации не покрывают всех деталей, а реализации в итоге предоставляют непортируемые решения. Например, это случилось с именами JNDI. При развертывании компонента EJB на серверах GlassFish, Jboss или WebLogic на каждом из них было свое собственное имя для JNDI, так как в спецификации оно не было явно указано. В код приходилось вносить изменения в зависимости от используемого сервера приложений. Эта конкретная проблема была устранена в Java EE, когда установили синтаксис для имен JNDI.
Сегодня платформа представила наиболее портируемые параметры конфигурации, увеличив таким образом портируемость. Несмотря на то что некоторые API были признаны устаревшими (отсечены), приложения Java EE сохраняют полную совместимость с предыдущими версиями, позволяя вашему приложению перемещаться до более новых версий сервера приложений без особых проблем.
Модель программирования
Большинство спецификаций Java EE 7 используют одну и ту же модель программирования. Обычно это POJO с некоторыми метаданными (аннотациями или XML), которые развертываются в контейнере. Чаще всего POJO даже не реализует интерфейс и не расширяет суперкласс. Благодаря метаданным контейнер знает, какие сервисы необходимо применить к этому развертываемому компоненту.
В Java EE 7 сервлеты, управляемые компоненты JSF, компоненты EJB, сущности, веб-службы SOAP и REST являются аннотированными классами с опциональными дескрипторами развертывания XML. Листинг 1.3 показывает управляемый компонент JSF, представляющий собой Java-класс с одиночной CDI-аннотацией.
@Named
public class BookController {