EJB 3 в действии

EJB 3 в действии
Автор: Дебу Панда, Реза Рахман, Райан Купрак, Майкл Ремижан
Год: 2015
ISBN: 978-5-97060-135-8
Страниц: 618
Язык: Русский
Формат: PDF
Размер: 10 Мб

Download

Фреймворк EJB 3 предоставляет стандартный способ оформления прикладной логики в виде управляемых модулей, которые выполняются на стороне сервера, упрощая тем самым создание, сопровождение и расширение приложений Java ЕЕ. Версия EJB 3.2 включает большее число расширений и более тесно интегрируется с другими технологиями Java, такими как CDI, делая разработку еще проще. Книга знакомит читателя с EJB на многочисленных примерах кода, сценариях из реальной жизни и иллюстрациях. Помимо основ в ней описываются некоторые особенности внутренней реализации, наиболее эффективные приемы использования, шаблоны проектирования, даются советы по оптимизации производительности и различные способы доступа, включая веб-службы, службы REST и веб-сокеты.
Издание предназначено программистам, уже знающим язык Java. Опыт работы с EJB или Java ЕЕ не требуется.

+

Первоначально технология EJB появилась под влиянием идей, заложенных в технологии распределенных вычислений, таких как CORBA, и предназначалась для поддержки масштабирования серверных приложений. Во время бума доткомов вокруг EJB и J2EE была поднята большая рекламная шумиха.

Первоначальной целью EJB было предоставить простую альтернативу технологии CORBA на основе стандартной инфраструктуры разработки и компонентов
многократного пользования. К моменту выхода EJB 2 стало очевидно, что эта инфраструктура превратилась в новый стандарт разработки серверных приложений. Она предоставляет промышленным разработчикам все необходимое – поддержку удаленных взаимодействий, механизмы управления транзакциями, средства обеспечения безопасности, обработки и хранения информации, и веб-службы – но все это были тяжеловесные механизмы, требующие от разработчиков основное внимание уделять особенностям взаимодействий с самой инфраструктурой, чем реализации бизнес-логики приложений. Из-за включения в EJB все новых особенностей, основатели этой инфраструктуры оказались не в состоянии справиться со все возрастающей сложностью.

С появлением недовольств, вызванных ограничениями в EJB 2, стали появляться новые инструменты с открытым исходным кодом. Эти инструменты являются
ярким признаком растущего недовольства сложностью Java EE. Однако, несмотря на благие намерения, эти инструменты еще больше осложнили разработку промышленных приложений, так как они отклонялись от стандартов, лежащих в основе сервера приложений, где эти инструменты должны использоваться. В этот период была запущен процесс Java Community Process (JCP) и сформирована экспертная группа для выполнения работ по упрощению разработки на основе Java EE. Это была единственная причина начала разработки Java EE 5 и EJB 3.

Для технологии с такой широкой областью применения, изменения в EJB 3 стали просто оглушительными. EJB 3 благополучно объединила в себе инновационные приемы, существенно упрощающие разработку компонентов. В число этих приемов входят: использование аннотаций, метапрограммирование, внедрение зависимостей, AspectJ-подобные интерцепторы и интеллектуальное использование значений по умолчанию. Произошел отказ от тяжеловесной модели программирования на основе наследования в пользу более легковесной модели на основе простых объектов Java (Plain Old Java Object, POJO), а подробные описания настроек на языке XML ушли с пути разработчика.

Обзор EJB

Первое, что следует выяснить при оценке новой технологии, – что она в действительности дает. Что же такого особенного в EJB? Помимо технологий уровня представления, таких как JavaServer Pages (JSP), JavaServer Faces (JSF) или Struts, разве нельзя создать веб-приложение на языке Java с использованием некоторого API, такого как Java Database Connectivity (JDBC) для доступа к базам данных? Конечно можно, если вы не ограничены жесткими временными рамками и ресурсами. До появления EJB именно так и работали. По опыту прошлых лет мы знаем, что в этом случае придется потратить массу времени на решение типовых задач системного уровня, вместо того, чтобы сосредоточиться на решении прикладных задач. Этот же опыт показывает, что типовые задачи имеют типовые решения. Это именно то, что с готовностью выкладывает на стол EJB. EJB – это коллекция «фиксированных» решений типовых проблем, возникающих при разработке серверных приложений, а также проверенная временем схема реализации серверных компонентов. Эти фиксированные решения, или службы, предоставляются контейнером EJB. Для доступа к этим службам необходимо создать специализированные компоненты, используя декларативные и программные EJB API, и развернуть их в контейнере.

Многоуровневые архитектуры и EJB

Корпоративные приложения проектируются для решения уникальных задач, и потому к ним предъявляется множество похожих требований. Большинство корпоративных приложений имеют некоторый пользовательский интерфейс, реализующий прикладные процессы, модель предметной области и хранение информации в базе данных. Так как эти требования являются общими, появляется возможность следовать обобщенной архитектуре, или принципам проектирования, известным как шаблоны проектирования.

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

EJB учитывает это обстоятельство и не способствует созданию универсальных компонентов на все случаи жизни. Вместо этого EJB следует модели специализированных компонентов, призванных решать задачи, свойственные определенному уровню в многоуровневой архитектуре. Существует две основные разновидности многоуровневых архитектур: традиционная четырехуровневая архитектура и проблемно-ориентированная архитектура (Domain-Driven Design, DDD). Давайте рассмотрим эти архитектуры в отдельности и выясним, как EJB соответствует им.

Проблемно-ориентированная архитектура

Термин проблемно-ориентированная архитектура (domain-driven design) может быть и является относительно новым, но само понятие существует достаточно
давно. Архитектура DDD подчеркивает, что объекты предметной области не должны служить простой заменой записей базы данных, и должны содержать прикладную логику. Эти объекты могут быть реализованы как сущности в JPA. В архитектуре DDD, объект Catalog в приложении электронной торговли, помимо хранения всех данных из таблицы каталога в базе данных, мог бы уметь анализировать и не возвращать записи из каталога, соответствующие отсутствующим на складе товарам. Будучи простыми объектами Java (POJO), сущности JPA поддерживают объектно-ориентированные возможности, такие как наследование и полиморфизм. Не составляет большого труда реализовать объектную модель хранилища на основе JPA и добавить в ее сущности прикладную логику. В настоящее время проблемно-ориентированная архитектура все еще использует уровень служб, или уровень приложения.

Почему стоит выбрать EJB 3?

В начале этой главы мы отмечали, что EJB является инновационной технологией, которая высоко подняла планку стандартов разработки серверных компонентов. Так же как и сам язык Java, EJB изменила окружающий мир, чтобы остаться в нем и послужить основой для множества других инноваций. Еще несколько лет назад серьезную конкуренцию EJB могла составить только платформа Microsoft .NET Framework. В этом разделе мы укажем на некоторые особенности EJB 3, которые по нашему мнению выводят эту последнюю версию в начало не такого уж и длинного списка.

Простота в использовании

Благодаря нацеленности на простоту использования, EJB 3 является, пожалуй, самой простой платформой для разработки серверных компонентов. Наиболее яркими аспектами с этой точки зрения являются: программирование POJO, преобладание аннотаций перед конфигурацией в формате XML, преимущественное использование значений по умолчанию и отказ от сложных парадигм. Несмотря на большое число служб в EJB, все они просты и понятны. По большей части технология EJB 3 выглядит весьма практично и не требует глубоко понимания всех ее теоретических хитросплетений. Фактически большинство служб EJB спроектировано так, чтобы вы могли не задумываться о них, сосредоточиться на решении прикладных задач и уходить домой в конце дня с осознанием, что достигнуто все желаемое.

Полный интегрированный стек решений

EJB 3 предлагает полный стек серверных решений, включая транзакции, безопасность, обмен сообщениями, планирование, удаленные взаимодействия, вебслужбы, асинхронная обработка, тестирование, внедрение зависимостей и интерцепторы. Это означает, что вам не придется тратить время на поиск сторонних инструментов для интеграции в свое приложение. Все необходимые службы уже имеются в наличии, и вам не придется делать что-то особенное, чтобы активировать их. Что ведет почти к полному отказу от систем конфигурации . Кроме того, EJB 3 обеспечивает бесшовную интеграцию с другими технологиями Java EE, такими как CDI, JPA, JDBC, JavaMail, Java Transaction API (JTA), JMS, Java Authentication and Authorization Service (JAAS), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI) и другими. EJB также гарантирует простоту интеграции с технологиями уровня представления, такими как JSP, Servlets и JSF. При необходимости с помощью CDI можно интегрировать с EJB и сторонние инструменты.

Широкая поддержка производителей

EJB поддерживается широким кругом независимых организаций. В их числе наиболее технологически развитые, наиболее уважаемые и финансово сильные
компании, такие как Oracle и IBM, а также активные и энергичные открытые проекты, такие как JBoss и Apache. Широкая поддержка производителей дает
три важных преимущества. Во-первых, вы не зависите от взлетов и падений каких-то компаний или групп людей. Во-вторых, у многих людей есть конкретный
долгосрочный интерес в максимальном сохранении конкурентоспособности технологии. Вы смело можете рассчитывать на возможность использования лучших технологий как внутри мира Java, так и за его пределами, в обозримом будущем. В-третьих, производители исторически конкурировали друг с другом, реализуя дополнительные нестандартные особенности. Все эти факторы помогают продвижению EJB по пути эволюции.

Связанные спецификации

EJB имеет две тесно связанные спецификации, которые мы покроем в этой книге. Первая из них: JPA, которая является стандартом хранения данных для Java EE и CDI, обеспечивает возможность внедрения зависимостей и предоставляет службы управления контекстом для всех компонентов Java EE, включая EJB.

Сущности и Java Persistence API

В EJB 3.1 был учтен переход JPA 2 от EJB 3 API к отдельной спецификации Java EE. Но JPA имеет множество специализированных точек интеграции с EJB, потому что эти две спецификации связаны теснее некуда. Здесь мы рассмотрим лишь некоторые аспекты JPA.

Технология хранения данных гарантирует автоматическое сохранение Java объектов в реляционной базе данных, такой как Oracle, SQL server или DB2. Управление хранимыми объектами осуществляется средствами JPA. Этот механизм автоматически сохраняет Java-объекты с применением объектно-реляционного отображения (Object-Relational Mapping, ORM). ORM – это процесс отображения полей Java-объектов в таблицы базы данных, определяемые с применением конфигурационных файлов или аннотаций. JPA освобождает от необходимости писать сложный, низкоуровневый код, использующий JDBC для сохранения объектов в базе данных.

Теперь вы должны иметь неплохое представление о том, что такое EJB 3, какие возможности она несет и почему следует задуматься об ее использовании в разработке серверных приложений. Мы коротко рассказали вам о новых особенностях EJB 3, включая следующие важные моменты:

  • компоненты EJB 3 – это простые Java-объекты (POJO), настраиваемые с помощью аннотаций;
  • доступ к компонентам EJB из клиентских приложений и модульных тестов сильно упростился, благодаря поддержке внедрения зависимостей;
  • EJB предоставляет полный комплект мощных и масштабируемых служб, что называется «из коробки».

Мы также показали, как выглядит программный код, использующий функции EJB 3. Получив эти знания, вам наверняка не терпится увидеть еще больше примеров. Готовьтесь, вас ждет головокружительный тур по EJB 3 API, в ходе которого мы покажем вам, насколько простым может быть код.

Первая проба EJB

  • приложение ActionBazaar;
  • сеансовые компоненты с сохранением и без сохранения состояния в приложении ActionBazaar;
  •  интеграция CDI и EJB 3;
  • сохранение объектов в JPA 2.

Реализация прикладной логики с применением EJB 3

Итак, приступим к исследованию решения, начав с уровня прикладной логики, как вы поступили бы в случае действующего приложения. Сеансовые компоненты EJB 3 идеально подходят для реализации процедур моделирования ставки и заказа. По умолчанию они поддерживают транзакции, многопоточную модель выполнения и возможность размещения в пулах – все характеристики, необходимые для построения прикладного уровня приложения. Сеансовые компоненты – самые простые, и вместе с тем самые универсальные элементы EJB 3, поэтому мы и начнем с них.

Напомним, что существует три разновидности сеансовых компонентов: с сохранением состояния, без сохранения состояния и компоненты-одиночки (singleton). В наших примерах мы будем использовать только сеансовые компоненты с сохранением и без сохранения состояния. Позднее нам также понадобятся компоненты, управляемые сообщениями (Message-Driven Beans, MDB). Для начала исследуем сеансовые компоненты без сохранения состояния, просто потому, что они проще.

Использование JPA 2 с EJB 3

Механизм JPA 2 де-факто является основным решением по хранению данных на платформе Java EE и тесно связан с EJB 3. В Java EE 5, механизм JPA был частью EJB 3. Если у вас есть опыт использования Hibernate, TopLink или JDO, вы будете чувствовать себя как дома, используя JPA 2. Большинство из этих инструментов в настоящее время поддерживает стандарт JPA 2.

Как уже отмечалось во введении, цель этой главы состояла не в том, чтобы дать вам «таблетку знания» EJB 3, а просто показать, чего можно ожидать от новой
версии платформы Java Enterprise.

Было начато создание приложения ActionBazaar, главной темы этой книги. На примере сценария работы этого приложения мы показали вам некоторые функциональные возможности EJB 3, включая сеансовые компоненты с сохранением и без сохранения состояния, CDI, JSF 2 и JPA 2. Познакомили вас с
некоторыми основными понятиями, такими как аннотации, внедрение зависимостей и объектно-реляционное отображение.

Мы попробовали использовать сеансовый компонент без сохранения состояния для реализации прикладной логики добавления новой ставки в аукционную
систему. А затем показали сеансовый компонент с сохранением состояния, инкапсулирующий логику процедуры оформления заказа. Вы увидели, как можно
тестировать компоненты EJB 3 с помощью JUnit, и как JSF 2, CDI и EJB 3 вместе обеспечивают бесшовные взаимодействия разных уровней приложения. В заключение мы исследовали порядок сохранения ставок в базе данных и использовали

EntityManager API для управления сущностями в базе данных. В следующей главе мы опустимся еще ниже и займемся более детальным изучением сеансовых компонентов.

Реализация прикладной логики с помощью сеансовых компонентов

  • сеансовые компоненты без сохранения состояния;
  • сеансовые компоненты с сохранением состояния;
  • компоненты-одиночки (singleton);
  • асинхронные компоненты.

Прикладная логика составляет основу любого корпоративного приложения. В идеальном мире разработчики должны основное свое внимание уделять реализации именно прикладной логики, тогда как такие задачи, как представление, хранение и интеграция по сути являются задачами оформительскими. С этой точки зрения наиболее важной частью технологии EJB составляют сеансовые компоненты, потому что цель всей их жизни заключается в моделировании бизнес-процессов.

Знакомство с сеансовыми компонентами

Независимо от типа, все сеансовые компоненты оптимально подходят для обращения к ним всех клиентов приложения. Клиентом может быть все, что угодно:
компонент веб-приложения (сервлет, страница JSF и так далее), приложение командной строки, другое приложение EJB и приложение с графическим интерфейсом на основе JavaFX/Swing. Клиентом может быть даже приложение Microsoft .NET, пользующееся веб-службой, или приложение для iOS или Android. Сеансовые компоненты обладают чрезвычайной мощью и могут использоваться для создания масштабируемых серверных систем, обслуживающих всех этих клиентов.

Контекст EJB времени выполнения, внедрение зависимостей и сквозная логика

  • основы EJBContext;
  • использование JNDI для поиска компонентов EJB и других ресурсов;
  • аннотация @EJB;
  • компоненты EJB в клиентских приложениях и встраиваемые контейнеры;
  • основы интерцепторов AOP.

Мы познакомились с контекстом EJB, узнали, как использовать аннотации @EJB и @Resource для внедрения зависимостей, и когда следует использовать непосредственный поиск ресурсов и компонентов EJB в реестре JNDI. Мы познакомились с аспектно-ориентированным программированием и показали, как
пользоваться интерцепторами EJB для реализации сквозной функциональности. В заключение мы сравнили интерцепторы EJB с более мощными интерцепторами CDI.

Транзакции и безопасность

  • основы использования транзакций в компонентах EJB;
  • когда следует использовать транзакции;
  • управление транзакциями на уровне контейнера и компонентов;
  • основы аутентификации и авторизации в компонентах EJB;
  • использование групп и ролей для поддержки безопасности.

Транзакции и безопасность – краеугольные камни, на которых строятся корпоративные приложения. С точки зрения разработки, механизмы поддержки транзакций и безопасности являются, пожалуй, наиболее сложными в реализации и практически не поддаются модификации после встраивания их в приложение. Оба механизма считаются системной сквозной функциональностью, пронизывающей прикладную логику и используемой ею. Спецификация EJB определяет особенности обоих механизмов и тем самым создает основу для создания надежных приложений, позволяя при этом программистам сосредоточиться на прикладных аспектах.

Для знакомых с основами JDBC заметим, что EJB создает дополнительный уровень поверх JDBC. Этот уровень вводит абстракции, которые иначе вам пришлось бы реализовать самим. JDBC – это механизм абстракций для организации взаимодействий с базами данных обобщенным способом с применением SQL; это не фреймворк. Создание масштабируемых приложений, использующих базы данных, требует гораздо большего, чем простая установка параметра автоматического подтверждения транзакций в значение false. Создание фреймворка управления транзакциями – далеко не тривиальная задача, и при его создании легко можно допустить ошибки в самых разных местах. В этой главе вы узнаете, как пользоваться транзакциями в EJB а также познакомитесь с приемами поддержки безопасности в своих приложениях.

Транзакции в Java

Теперь вы имеете основные представления о транзакциях и их важности. Транзакции необходимы; без них переходные состояния были бы доступны другим
пользователям и вызывали хаос в данных. В отсутствие поддержки транзакция вам пришлось бы вручную реализовать собственные механизмы блокировок, синхронизации и отката изменений. Реализация таких механизмов невероятно сложна, поэтому разработка системы транзакций может потребовать по-настоящему титанических усилий. К счастью практически все современные базы данных поддерживают ACID-совместимые транзакции. Давайте теперь перейдем от теоретических рассуждений о транзакциях к практике и посмотрим, как используются транзакции для доступа к базам данных из программ на языке Java.