Изучаем Java EE 7 - [8]

Таблица 1.1. Дескрипторы развертывания в Java EE0

Файл	Спецификация	Местоположение
application.xml	Java EE	META-INF
application-client.xml	Java EE	META-INF
beans.xml	CDI	META-INF или WEB-INF
ra.xml	JCA	META-INF
ejb-jar.xml	EJB	META-INF или WEB-INF
faces-config.xml	JSF	WEB-INF
persistence.xml	JPA	META-INF
validation.xml	Валидация компонентов	META-INF или WEB-INF
web.xml	Сервлет	WEB-INF
web-fragment.xml	Сервлет	WEB-INF
webservices.xml	Веб-службы SOAP	META-INF или WEB-INF

Начиная с Java EE 5, большинство дескрипторов развертывания опциональны, и вместо них можно использовать аннотацию. Но вы также можете взять для вашего приложения наилучшее от обоих методов. Самое большое преимущество аннотаций в том, что они могут значительно сократить количество кода, который необходимо написать разработчику. Кроме того, используя аннотацию, вы можете избежать необходимости в дескрипторе развертывания. С другой стороны, дескрипторы развертывания — это внешние XML-файлы, для замены которых не требуется изменений исходного кода и рекомпиляции. Если вы используете сразу оба метода, то во время развертывания приложения или компонента метаданные переопределяются дескриптором развертывания (то есть XML приоритетнее аннотаций).

Примечание

Сегодня в Java-программировании предпочтительнее использование аннотаций, а не дескрипторов развертывания. Это происходит в рамках тенденции перехода от двуязычного программирования (Java + XML) к одноязычному (Java). Точно так же приложение проще анализировать и создавать его прототип, когда все (данные, методы и метаданные с аннотациями) хранится в одном месте.

Java EE использует понятие программирования путем исключения (также известное как программирование по соглашениям), когда большая часть общего поведения не требует сопровождения метаданными («в программировании метаданные являются исключением, контейнер заботится о настройках по умолчанию»). Это означает, что даже при малом количестве аннотаций или XML контейнер может выдать стандартный набор настроек с заданным по умолчанию поведением.

Стандарты

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

В самом начале развития 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.