Изучаем Java EE 7

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

Сервисы

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

• Java API для транзакций — этот сервис предлагает интерфейс разграничения транзакций, используемый контейнером и приложением. Он также предоставляет интерфейс между диспетчером транзакций и диспетчером ресурсов на уровне интерфейса драйвера службы.

• Интерфейс сохраняемости Java — стандартный интерфейс для объектно-реляционного отображения (ORM). С помощью встроенного языка запросов JPQL вы можете обращаться к объектам, хранящимся в основной базе данных.

• Валидация — благодаря валидации компонентов объявляется ограничение целостности на уровне класса и метода.

• Интерфейс Java для доступа к службам сообщений — позволяет компонентам асинхронно обмениваться данными через сообщения. Он поддерживает надежный обмен сообщениями по принципу «от точки к точке» (P2P), а также модель публикации-подписки (pub-sub).

• Java-интерфейс каталогов и служб именования (JNDI) — этот интерфейс, появившийся в Java SE, используется как раз для доступа к системам служб именования и каталогов. Ваше приложение применяет его, чтобы ассоциировать (связывать) имена с объектами и затем находить их в каталогах. Вы можете задать поиск источников данных, фабрик классов JMS, компонентов EJB и других ресурсов. Интерфейс JNDI, повсеместно присутствовавший в коде до версии 1.4 J2EE, в настоящее время используется более прозрачным способом — через внедрение.

• Интерфейс JavaMail — многим приложениям требуется функция отправки сообщений электронной почты, которая может быть реализована благодаря этому интерфейсу.

• Фреймворк активизации компонентов JavaBeans (JAF) — интерфейс JAF, являющийся составной частью платформы Java SE, предоставляет фреймворк для обработки данных различных MIME-типов. Используется сервисом JavaMail.

• Обработка XML — большинство компонентов Java EE могут развертываться с помощью опциональных дескрипторов развертывания XML, а приложениям часто приходится манипулировать XML-документами. Интерфейс Java для обработки XML (JAXP) поддерживает синтаксический анализ документов с применением интерфейсов SAX и DOM, а также на языке XSLT.

• Обработка JSON (объектной нотации JavaScript) — появившийся только в Java EE 7 Java-интерфейс для обработки JSON (JSON-P) позволяет приложениям синтаксически анализировать, генерировать, трансформировать и запрашивать JSON.

• Архитектура коннектора Java EE — коннекторы позволяют получить доступ к корпоративным информационным системам (EIS) с компонента Java EE. К таким компонентам относятся базы данных, мейнфреймы либо программы для планирования и управления ресурсами предприятия (ERP).

• Службы безопасности — служба аутентификации и авторизации для платформы Java (JAAS) позволяет сервисам аутентифицироваться и устанавливать права доступа, обязательные для пользователей. Контракт поставщика сервиса авторизации Java для контейнеров (JACC) определяет соглашение о взаимодействии между сервером приложений Java EE и поставщиком сервиса авторизации, позволяя, таким образом, сторонним поставщикам такого сервиса подключаться к любому продукту Java EE. Интерфейс поставщика сервисов аутентификации Java для контейнеров (JASPIC) определяет стандартный интерфейс, с помощью которого модули аутентификации могут быть интегрированы с контейнерами. В результате модули могут установить идентификаторы подлинности, используемые контейнерами.

• Веб-службы — Java EE поддерживает веб-службы SOAP и RESTful. Интерфейс Java для веб-служб на XML (JAX-WS), сменивший интерфейс Java с поддержкой вызовов удаленных процедур на основе XML (JAX-RPC), обеспечивает работу веб-служб, работающих по протоколу SOAP/HTTP. Интерфейс Java для веб-служб RESTful (JAX-RS) поддерживает веб-службы, использующие стиль REST.

• Внедрение зависимостей — начиная с Java EE 5, некоторые ресурсы могут внедряться в управляемые компоненты. К таким ресурсам относятся источники данных, фабрики классов JMS, единицы сохраняемости, компоненты EJB и т. д. Кроме того, для этих целей Java EE 7 использует спецификации по контексту и внедрению зависимости (CDI), а также внедрение зависимости для Java (DI).

• Управление — Java EE с помощью специального управляющего компонента определяет API для операций с контейнерами и серверами. Интерфейс управляющих расширений Java (JMXAPI) также используется для поддержки управления.

• Развертывание — спецификация Java EE по развертыванию определяет соглашение о взаимодействии между средствами развертывания и продуктами Java EE для стандартизации развертывания приложения.

Сетевые протоколы

Как показано на рис. 1.2, компоненты, развертываемые в контейнерах, могут вызываться с помощью различных протоколов. Например, сервлет, развертываемый в веб-контейнере, может вызываться по протоколу HTTP, как и веб-служба с конечной точкой EJB, развертываемый в EJB-контейнере. Ниже приводится список протоколов, поддерживаемых Java EE.

Рис. 1.2. Сервисы, предоставляемые контейнерами

• HTTP — веб-протокол, повсеместно используемый в современных приложениях. В Java SE клиентский API определяется пакетом java.net. Серверный API для работы с HTTP определяется сервлетами, JSP-страницами, интерфейсами JSF, а также веб-службами SOAP и RESTful.

• HTTPS — представляет собой комбинацию HTTP и протокола безопасных соединений SSL.

• RMI–IIOP — удаленный вызов методов (RMI) позволяет вызывать удаленные объекты независимо от основного протокола. В Java SE нативным RMI-протоколом является протокол Java для удаленного вызова методов (JMRP). RMI–IIOP представляет собой расширение технологии RMI, которое используется для интеграции с архитектурой CORBA. Язык описания Java-интерфейсов (IDL) позволяет компонентам приложений Java EE вызывать внешние объекты CORBA с помощью протокола IIOP. Объекты CORBA могут быть написаны на разных языках (Ada, C, C++, Cobol и т. д.), включая Java.

Упаковка

Для последующего развертывания в контейнере компоненты сначала необходимо упаковать в стандартно отформатированный архив. Java SE определяет файлы архива Java (формат JAR), используемые для агрегации множества файлов (Java-классов, дескрипторов развертывания, ресурсов или внешних библиотек) в один сжатый файл (на основе формата ZIP). Как видно на рис. 1.3, Java EE определяет различные типы модулей, имеющих собственный формат упаковки, основанный на общем формате JAR.

Рис. 1.3. Архивы в контейнерах

• Модуль клиентских приложений содержит Java-классы и другие ресурсные файлы, упакованные в архив JAR. Этот файл может выполняться в среде Java SE или в контейнере клиентского приложения. Как любой другой архивный формат, JAR-файл содержит опциональный каталог META-INF для мета-информации, описывающей архив. Файл META-INF/MANIFEST.MF используется для определения данных, относящихся к расширениям и упаковке. При развертывании в контейнере клиентских приложений соответствующий дескриптор развертывания может быть опционально размещен по адресу META-INF/application-client.xml.

• Модуль EJB содержит один или несколько компонент-сеансов и/или компонентов, управляемых сообщениями (MDB), упакованных в архив JAR (часто называемый JAR-файл EJB). Он содержит опциональный дескриптор развертывания META-INF/ejb-jar.xml и может развертываться только в контейнере EJB.

• Модуль веб-приложений содержит сервлеты, страницы JSP и JSF, веб-службы, а также любые другие файлы, имеющие отношение к Сети (страницы HTML и XHTML, каскадные таблицы стилей (CSS), Java-сценарии, изображения, видео и т. д.). Начиная с Java EE 6 модуль веб-приложения также может содержать компоненты EJB Lite (подмножество интерфейса EJBAPI, описанное в главе 7). Все эти артефакты упаковываются в архив JAR с расширением WAR (также называемый архивом WAR или веб-архивом). Опциональный веб-дескриптор развертывания определяется в файле WEB-INF/web.xml. Если архив WAR содержит компоненты EJB Lite, то файл WEB-INF/ejb-jar.xml может быть снабжен опциональным дескриптором развертывания. Java-файлы с расширением. class помещаются в каталог WEB-INF/classes, а зависимые архивные JAR-файлы — в каталог WEB-INF/lib.

• Корпоративный модуль может содержать нуль или более модулей веб-приложений, модулей EJB, а также других общих или внешних библиотек. Они упаковываются в корпоративный архив (файл JAR с расширением. ear) таким образом, чтобы развертывание всех этих модулей происходило одновременно и согласованно. Опциональный дескриптор развертывания корпоративного модуля определяется в файле META-INF/application.xml. Специальный каталог lib используется для разделения общих библиотек по модулям.

Аннотации и дескрипторы развертывания

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

Как вы могли видеть на рис. 1.2, компоненты выполняются в контейнере, который, в свою очередь, дает компоненту набор сервисов. Метаданные используются для объявления и настройки этих сервисов, а также для ассоциирования с ними дополнительной информации, наряду с Java-классами, интерфейсами, конструкторами, методами, полями либо параметрами.

Начиная с Java EE 5, количество аннотаций в корпоративной платформе неуклонно растет. Они декорируют метаданными ваш код (Java-классы, интерфейсы, поля, методы). Листинг 1.1 показывает простой Java-объект в старом стиле (POJO), объявляющий определенное поведение с использованием аннотаций к классу и к атрибуту (подробнее о компонентах EJB, контексте хранения и аннотациях — в следующих главах).

Листинг 1.1. Компонент EJB с аннотациями

@Stateless

@Remote(ItemRemote.class)

@Local(ItemLocal.class)

@LocalBean

public class ItemEJB implements ItemLocal, ItemRemote {

··@PersistenceContext(unitName = "chapter01PU")

··private EntityManager em;

··public Book findBookById(Long id) {

····return em.find(Book.class, id);

··}

}

Второй способ объявления метаданных — использование дескрипторов развертывания. Дескриптор развертывания (DD) означает файл XML-конфигуратора, который развертывается в контейнере вместе с компонентом. Листинг 1.2 показывает дескриптор развертывания компонента EJB. Как и большинство дескрипторов развертывания в Java EE 7, он определяет пространство имен http://xmlns.jcp.org/xml/ns/javaee и содержит атрибут версии с указанием версии спецификации.

Листинг 1.2. Дескриптор развертывания компонента EJB

<ejb-jar xmlns="http://xmlns.jcp.org/xml/ns/javaee" 

·········xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance" 

·········xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 

·······················http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd" 

·········version="3.2" >

··<enterprise-beans>

····<session>

······<ejb-name>ItemEJB</ejb-name>

······<remote>org.agoncal.book.javaee7.ItemRemote</remote>

······<local>org.agoncal.book.javaee7.ItemLocal</local>

······<local-bean/>

······<ejb-class>org.agoncal.book.javaee7.ItemEJB</ejb-class>

······<session-type>Stateless</session-type>

······<transaction-type>Container</transaction-type>

····</session>

··</enterprise-beans>

</ejb-jar>

Для того чтобы дескрипторы развертывания учитывались при работе, они должны упаковываться вместе с компонентами в специальный каталог META-INF или WEB-INF. В табл. 1.1 приведен список дескрипторов развертывания Java EE и соответствующая спецификация (подробнее об этом читайте в следующих главах).

Таблица 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.

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

Модель программирования

Большинство спецификаций Java EE 7 используют одну и ту же модель программирования. Обычно это POJO с некоторыми метаданными (аннотациями или XML), которые развертываются в контейнере. Чаще всего POJO даже не реализует интерфейс и не расширяет суперкласс. Благодаря метаданным контейнер знает, какие сервисы необходимо применить к этому развертываемому компоненту.

В Java EE 7 сервлеты, управляемые компоненты JSF, компоненты EJB, сущности, веб-службы SOAP и REST являются аннотированными классами с опциональными дескрипторами развертывания XML. Листинг 1.3 показывает управляемый компонент JSF, представляющий собой Java-класс с одиночной CDI-аннотацией.