Java ee — Java EE. Что можно реализовать


Содержание

Java EE 7 — Введение

Всем привет. Несколько дней назад я написал о том, что хочу изучать Java EE 7. Там же я написал, что планирую ежедневно писать конспекты по полученным материалам. Что из этого вышло? Читайте в этом посте.

Как я и хотел, я начал изучать Java EE с помощью официального туториала по Java EE 7. Честно сказать, я не осилил его. Всё написано как-то уж больно сухо (хотя, чего ещё хотеть от документации).

Прочитав 2 главы туториала, узнал про общую архитектуру Java EE, узнал о том, как ставить GlassFish — канонический сервер приложений, узнал, как деплоить приложения. На этом, наверное, всё. Поэтому, решил начать читать книжку, а туториал оставить на потом.

На сегодняшний день существует несколько книжек по Java EE 7. Это Java EE 7 with GlassFish 4 Application Server , это Beginning Java EE 7 . Прочитав отзывы к обоим книжкам, выбрал первую.

В Java EE 7 with GlassFish 4 Application Server содержится всего 350 страниц. Тут нет каких-то длинных введений, сразу идёт рассказ по существу. Обсуждаются такие понятия, как EJB, JPA, JSF, а также ряд других API.

Честно сказать, пока прочитал только порядка 50%. И, надо признаться, книжка не очень понравилась. Всё как-то сильно просто и очевидно (может, это благодаря моему бекграунду в ASP.NET MVC).

Отдельно стоит отметить, что в этой книжке используется крайне простой английский (даже я, с моим ужасным английским, могу читать книгу практически без словаря).

Сегодня на хабре мне посоветовали обратить своё внимание на 2-ю из этих книжек (то есть, на Beginning Java EE 7 ). Возможно, попробую почитать и её.

Введение в Java EE 7

Итак, что же мне удалось узнать про Java EE 7 за эти несколько дней? Перейдём наконец-то к введению в эту технологию.

Java EE 7 — это набор стандартов, которые описывают массу различных API. Каждый из стандартов описывает конкретную технологию, причём, некоторые из этих технологий могут использоваться и в Java SE.

Так как Java EE — это только описание технологий (то есть, их декларация), то нужно кому-то предоставить и имплементацию этих вещей (то есть, реализацию технологий). Не стоит волноваться: простому разработчику не придётся программировать реализацию стандарта. Разные компании создают свои продукты — Серверы приложений, которые как раз таки и содержат реализации всех стандартов из соответствующей версии Java EE.

На сегодняшний день существует несколько серверов приложений, которые реализуют Java EE 7. Это референсная реализация GlassFish 4 от Oracle, и это крайне популярный Open Source сервер WildFly.

Считается, что сервер приложений — это имплементация всех стандартов из описания Java EE, а также ряд дополнительных фич. Поэтому, в теории, вы легко сможете менять сервер приложений, и всё должно и дальше работать нормально.

Структура Java EE приложения

Дальше я бы хотел рассказать о структуре Java EE приложения. Это модульное приложение, состоящее из нескольких слоев. Первый слой — это клиентская часть приложения (как я понял, это аналог View в ASP.NET MVC). Технология, которая реализует этот уровень, называется JavaServer Faces. JSF — это, грубо говоря, продвинутый шаблонизатор с набором предустановленных компонентов, которые можно использовать при верстке.

Существуют и другие подходы к реализации клиентской части приложений. Во-первых, это Сервлеты — классы, которые способны принимать HTTP запросы и отвечать на них своими HTTP ответами. Думаю, что можно сказать, что аналогом Сервлета в ASP.NET MVC является класс Controller.

Есть и третий подход к реализации клиента — полноценный UI на основе какого-нибудь MV* javascript фреймворка + взаимодействие с сервером по RESTful (JAX-RS).

Следующий слой стандартного Java EE приложения — это сервисы, в которых описывается бизнес логика. Для этого используется технология Enterprise JavaBeans (EJB). Грубо говоря, это несколько типов различных классов (с сохранением состояния между запросами, без сохранения состояния между запросами, с использованием сервера очередей).

В EJB описываются различные сервисы. Например, есть класс UserService, и там описываются такие методы, как getUser, saveUser, removeUser.

Для доступа к данным используется ещё один стандарт — Java Persistence API (JPA). Конечно же, это опять только декларация технологии, а ещё нужна имплементация. В серверах приложений присутствует эта имплементация. Есть и независимые реализации JPA. Например, популярная ORM Hibernate как раз таки реализует JPA.

Отдельно стоит упомянуть интересную систему внедрения зависимостей. Стандарт, который описывает это дело, называется Contexts and Dependency Injection (CDI). Эта технология позволяет получить нужные зависимости некоторых типов (например, доступ к БД) всего-лишь с помощью одной аннотации над соответствующей переменной.

Больше рассказывать о Java EE я, к сожалению, не буду, так как знаком с этой технологией лишь неделю и боюсь наделать много ошибок. Пока понял, что существует большое количество API, которые необходимо умело комбинировать, для того чтобы сделать рабочее приложение.

Кстати, я уже решил, что буду делать в качестве «домашнего задания». Скоро подробно напишу об этом.

Java EE

JAVA EE: Разработка web-приложения. Дизайн и настройка.

Третья статья по разработке web-приложения.

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

Также мы рассмотрим способ подключение IDE к базе данных MySQL, создадим новую базу данных для нашего web-приложения.

Разрабатываемый нами сайт будет подобием мини-блога с возможностью чтения, добавления и редактирования статей. Также будет реализован функционал регистрации пользователей, комментирования статей и распределения прав доступа. Это первоначальный набор возможностей, который будет реализован, в дальнейшем будем вырабатывать новые требования к системе.

Структура сайта

Из приведенного выше описания можно составить структуру сайта:

  1. Главная страница сайта. Содержит список последних добавленных статей.
  2. Страница чтения статьи. Содержит полное содержание выбранной статьи.
  3. Страница регистрации.
  4. Зона администрирования. Ограниченный вход только для авторизованных пользователей, имеющих права администратора сайта.

Наглядно расписанную структуру можно увидеть на рисунке ниже:

Архитектура Java EE проекта

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

При работе с JSP можно уместить бизнес-логику внутри jsp страниц с использованием скриплетов , однако такой подход не рекомендуется даже для малых проектов. Причин, почему этот подход является плохим, можно найти множество на просторах интернета, в частности:

  1. Скриплеты не масштабируемы и трудно поддерживаемы.
  2. Смесь программирования, верстки и дизайна в одном флаконе: верстальщик явно не обрадуется, глядя на jsp страницу с кучей непонятного для него кода.
  3. Читать такие страницы крайне неудобно.
  4. Сложность тестирования.

И это список далеко неполный.

Из вышесказанного выведем еще одно важное правило:

1Не злоупотребляйте, а лучше старайтесь не использовать скриплеты внутри jsp страниц.

В данной серии статей мы будем следовать паттерну MVC. Паттерн достаточно известный и подробно вдаваться в его подробности не имеет смысла.

Опишем основные моменты.

  • Модель (M Model): Хранит в себе бизнес-логику приложения, регулирует доступ к данным и их изменение.
  • Вид (V View): View отображает содержимое модели, определят как необходимо представить данные, полученные от модели. View берет на себя сбор пользовательских данных и передачи их контроллеру.
  • Контроллер (C Controller): Контроллер определяет поведение всего приложения, получает от view пользовательские данные, интерпретирует их в действия, выполняемые с помощью модели. Контроллер передает view указание, какое представление необходимо применить, на основе результатов работы модели и взаимодействия с пользователем.

Применительно к Java EE технологии шаблон MVC реализуется следующим образом. Сервлет используется как контроллер для обработки входящих запросов пользователей от представления, которое реализуется с помощью страниц jsp. Модель же представляет собой EJB сессионные компоненты, а также классы сущности (JPA), которые в свою очередь содержат в себе данные из БД.

Создание web-проекта

Приступим к работе со средой разработки.

1. Запустите Ваше IDE. Автор использует NetBeans.

2. Кликните по иконке «Создать проект. » , в списке категорий выберите «Java Web», в появившемся списке «Проекты» выберите «Веб-приложение».

3. Нажмите «Далее >». Введите наименование проекта «myblog».

4. Сервер и параметры настройки. Далее Вам необходимо выбрать сервер и версию Java EE платформы. Если в списке серверов нет Вашего сервера, то добавьте его, используя кнопку «Добавить».

После завершения всех настроек нажмите кнопку «Готово».

IDE сформирует каркас Вашего приложения. Имеется один файл index.jsp с простенькой разметкой. Это вполне работоспособный скелет приложения. Нажмите на кнопку «Запустить главный проект» или F6. В результате IDE развернет на выбранном вами сервере данное веб-приложение. Протестить его можно по перейдя по ссылке:

Чтобы посмотреть список развернутых приложений на сервере, перейдите на вкладку «Службы», раскройте выпадающий список «Серверы», в нем выберите ваш и в нем найдите список «приложения».

Взаимодействие IDE с базой данных

Подключим IDE к нашей базе данных. Для этого выполним простые действия.

1. На вкладке «Службы» кликните правой кнопкой мыши и в появившемся контекстном меню выберите пункт «Зарегистрировать сервер MySQL».

2. По умолчанию имя узла и номер порта сервера совпадают с предложенными. Вам нужно ввести ваше имя пользователя и пароль. Нажмите ОК.

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

Шаблоны страниц

Далее создадим несколько шаблонов наших страниц. Для этого нажмите на кнопку «Создать файл. » . Выберите тип файла «JSP» и нажмите «Далее. «, введите название страницы Article и нажмите «Готово«. Подобным же образом создайте jsp файл Registration.

Теперь создайте папку «css» в корневом каталоге и добавьте новую каскадную страницу стилей style.

В результате дерево проекта у Вас должно выглядеть следующим образом:

Можно посмотреть каждую из страниц, набрав в адресной строке браузера строку типа localhost:8080/article.jsp

Теперь произведем небольшую верстку сайта. Откройте файл index.jsp и добавьте в него следующий код.

Файл article.jsp будет отличать лишь то, что блок article у него будет встречаться единожды, поэтому скопируйте этот же код в файл article.jsp за исключением того, что блог div будет выглядеть вот так:

Файл registration.jsp.

Файл style.css будет содержать следующий код.

Можете вновь зайти на каждую из страниц и посмотреть что у нас получилось. Выглядеть должно примерно вот так:

На этом третья статья серии закончена.

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


Комментарии

12.02.2020 Автор: Дмитрий

Здравствуйте, автору спасибо , почему то только нашел ваш сайт. Материалы будут новые?

17.06.2020 Автор: Abay

Планирую изучить Java + Web, но тупое копирование кода вряд ли поможет достичь хороших результатов.

Блог сурового челябинского программиста

Are you aware how much time I’ve spent learning for details of Java? Thread management, dynamics, CORBA.

суббота, 16 августа 2014 г.

Опыт реального использования практически всех возможностей Java EE 6

Модульность и развертывание

Начну разговор с рассказа о наиболее общем, т.е. о сборке приложения и его развертывании. Сборка приложения осуществляется с помощью Apache Maven, в качестве среды разработки, тестирования и промышленной эксплуатации используется сервер приложений Oracle WebLogic 12c (12.1.2). Многие разработчики и я — не исключение, поистине любят Apache Maven за его декларативность, модульность и интеграцию с Java EE, что называется из коробки. Нужно лишь указать правильный тип собираемого артефакта (packaging) и любой тип Java EE-модуля будет собран, будь то EAR, WAR, EJB-JAR или обычный всем нам хорошо знакомый JAR с какой-нибудь библиотекой. Однако при необходимости, процесс сборки можно кастомизировать, подключив и настроив соответствующий плагин.

Спецификация Java EE 6 привнесла такие новшества, как возможность полностью отказаться от дескрипторов развертывания. Сервлеты теперь можно определять с помощью аннотаций, что в большинстве случаев сводит на нет необходимость в файле web.xml. Чтобы Apache Maven игнорировал отсутствие данного файла, необходимо правильно настроить плагин maven-war-plugin:

Стоит отметить, что данных настроек достаточно, даже если в WEB-модуле находятся EJB-компоненты, дополнительно настраивать плагин maven-ejb-plugin нет необходимости.

Отдельно стоит поговорить о модульности. В принципе, Java EE изначально разрабатывалась как модульная технология. В Java EE 6 система модулей была существенно улучшена: теперь нет необходимости выносить EJB-компоненты в отдельный модуль ejb-jar. Небольшое приложение, состоящее из веб- и EJB-частей может целиком разворачиваться как один WAR-архив. Если же приложение побольше, то все равно применение комбинированных WEB-EJB модулей существенно упростит жизнь системного администратора.

Развертывание на сервере приложений Oracle WebLogic 12c так же осуществляется посредством Apache Maven. Начиная с 12-й версии у сервера приложений появился довольно удобный Maven-плагин, позволяющий как управлять жизненным циклом сервера и домена, так и осуществлять развертывание, запуск, останов и обновление приложений.

Впечатления: в рассматриваемом случае было разработано восемь модулей, собираемых в два EAR-архива: один архив содержит приложение, собственно осуществляющее интеграцию, другой — управляющее приложение с веб-интерфейсом. Данное решение позволяет обновлять основную часть, не затрагивая веб-интерфейс, с которым в момент обновления могут работать люди. В случае необходимости вынесения EJB в отдельные модули работы было бы больше.

Организация бизнес-логики

Одним из самых радикальных нововведений в Java EE 6 стало появление мощного IoC-контейнера под названием Contexts and Dependency Injection (CDI). Если в Java EE 5 появилась только лишь возможность инъектировать EJB в сервлеты и другие EJB, то сейчас ситуация существенно изменилась. Посредством CDI могут инъектироваться как все управляемые компоненты (EJB и Managed Beans), так и ресурсы (например, Data Sources) и даже обычные классы. Настройка инъектирования больше похожа на Google Guice, нежели на более привычный Spring Framework, который хоть уже давно и поддерживает аннотации, но многие вещи, особенно требующие доступа к ресурсам, таким как источники данных, по прежнему удобнее и проще настраивать через XML.

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

Классы, объекты которых будут инъектироваться:

Определение точек инъекции:

Другая решаемая посредством CDI проблема — доступ к ресурсам. Например, в приложении необходимо построить реализацию паттерна DAO, в которую поместить ссылку на источник данных. Реализуется такая инъекция с помощью специальных методов — продюсеров, аннотированных @javax.enterprise.inject.Produces:

В рассматриваемом приложении использование CDI позволило реализовать такие затратные по числу классов и инъекций паттерны, как Query Object, а так же избавило от необходимости делать каждый класс EJB-компонентом. Более того, рекомендуется даже управляемые компоненты JSF определять через CDI (с помощью аннотации @javax.inject.Named), а сами EJB инъектировать с помощью аннотации @javax.inject.Inject, а не @javax.ejb.EJB.

Дополнительно CDI поддерживает интерцепторы, что помогает задействовать AOP, а так же позволяет публиковать и подписываться на события, но в рассматриваемом примере эти возможности не задействованы.

Впечатления: в целом очень даже положительные. Но заметен ад аннотаций, их действительно приходится писать слишком много. В рассматриваемом случае их число удалось бы сильно сократить, если бы CDI мог определять инъекцию не только по типу самого поля, но и по типу дженерика для данного поля аналогично тому, как это делает Spring Framework. Так же следует отметить, что для CDI-компонентов не поддерживаются декларативные настройки безопасности. Такие настройки доступны только для EJB.

Управление транзакциями осуществляется посредством EJB-компонентов. В приложении используются управляемые контейнерами транзакции (CMT), демаркация границ которых осуществляется посредством стандартных аннотаций @javax.ejb.TransactionAttribute. В принципе, данные настройки появились еще в Java EE 5. Существенные изменения в управление транзакциями внесены в спецификации Java EE 7: теперь контейнер может оборачивать в транзакции и методы CDI-компонентов, что во многих случаях позволяет полностью отказаться от использования EJB.

Запускаемые при старте приложения компоненты

Инъекция зависимостей как в EJB-, так и в CDI-компоненты ленивая, т.е. инъектируемый объект будет построен только если выполняется построение зависящего от него компонента. Чтобы построить, например, кэш каких-либо данных, необходимо, чтобы из некоторой точки программы было обращение к содержащему данный кэш объекту. В Java EE 6 ситуация изменилась: чтобы компонент был построен во время запуска приложения, его необходимо аннотировать @javax.ejb.Startup. При этом будет выполнен метод компонента, аннотированный @javax.annotation.PostConstruct. В данном методе можно загрузить объекты в кэш, запустить таймеры или выполнить другие действия.

Если необходимо, чтобы компонент был построен после успешного запуска какого-либо другого компонента, то его необходимо аннотировать @javax.ejb.DependsOn, указав в качестве параметра аннотации наименование интересующего компонента.

К сожалению автоматически запускаемыми могут быть только т.н. Singleton Session Beans — новый тип EJB-компонентов, появившийся в Java EE 6.

Singleton Session Beans

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

Singleton Session Bean работает аналогично сервлету: создается один и только один экземпляр компонента. При этом по-умолчанию доступ ко всем бизнес-методам такого экземпляра организуется строго последовательно, т.е. два клиента не могут одновременно вызвать его метод.

Управляется данное поведение с помощью аннотации @javax.ejb.Lock. Данная аннотация принимает на вход значение из перечисления javax.ejb.LockType. По-умолчанию данное значение равно javax.ejb.LockType.WRITE, что приводит к организации последовательного доступа к методам. Если в каком-либо методе не производится изменение состояния общих объектов и он может выполняться в многопоточной среде, то его можно аннотировать @Lock(LockType.READ), тогда будет разрешено одновременное выполнение метода из нескольких потоков.

Впечатления: в рассматриваемом приложении автоматически запускаемые синглетные компоненты используются для управления таймерами, отвечающими за загрузку данных по расписанию. Аннотация @DependsOn используется для указания порядка запуска компонентов: сначала считывающий и периодически обновляющий конфигурацию приложения, затем — выполняющий основную работу. Так как таймеров создается несколько и все используют один и тот же метод timeout, то пришлось разрешить многопоточное исполнение данного метода с помощью аннотации @Lock.

Новое представление EJB-компонентов: без интерфейса

В Java EE 6 к двум существовавшим ранее представлениям EJB-компонентов: удаленному и локальному интерфейсам, добавилось третье: представление компонента без интерфейса. Суть в следующем: теперь EJB компонент может не иметь ни локального, ни удаленного интерфейсов. В точках инъекции EJB-компонентов можно использовать сразу имя конкретного класса.

Хотя лучше конечно так не делать — не определять поля, тип которых — конкретный класс. Инъекцию лучше осуществлять посредством интерфейсов. Иначе будет очень сложно подменить реализацию при необходимости. Полезно же безынтерфейсное представление EJB-компонентов в том случае, когда они не предназначены для инъекции. Т.е. представляют собой или автоматически стартуемый синглетный компонент, осуществляющий регистрацию таймеров или выполнение каких-либо других действий по инициализации приложения, либо веб-сервисный фасад. Еще в EJB 2.1 появилась возможность предоставить доступ к компоненту посредством механизма веб-сервисов. Понятно, что иметь интерфейс (в терминах Java) такому компоненту абсолютно незачем. Необходимость поддержки такого интерфейса только лишь добавляет работы разработчикам: при расширении нужно добавлять метод и в интерфейс, и в реализацию, когда на самом деле он нужен только в последней.

Работа с настройками приложения

Пункт, для реализации которого в Java EE 6 нет ничего. Стандартного API, кроме предназначенного для работы с .properties-файлами, не существует. Но одними .properties-файлами сыт не будешь. В рассматриваемом примере было реализовано сохранение настроек приложения в базе данных в виде сериализуемого в CLOB XML. Работа с XML ведется с помощью JAXB. В принципе, применять для хранения настроек базу данных довольно избыточно, но с другой стороны спецификация не приветствует работу с файловой системой сервера. На мой взгляд обобщенного хорошего API для работы с конфигурацией приложения платформе очень не хватает.

Разработка веб-интерфейса

Существенным прорывом в Java EE 6 стала спецификация JSF 2, описывающая MVC-фреймворк для разработки веб-интерфейса приложения. Нововведений по сравнению с предыдущей версией очень много. Прежде всего это конечно новый механизм описания разметки — фейслеты (facelets). Прощай, прощай, JSP, ты нас утомил. В фейслетах улучшена интеграция с JSTL, которая была довольно таки кривая в JSF 1.2. Радует, что теперь из разметки можно явно вызвать метод управляемого компонента и передать ему параметры, иногда это необходимо. Так же очень облегчает жизнь применение шаблонов, теперь страница строится путем встраивания специфичных фрагментов в обобщенный шаблон, что помогает обеспечить единый вид для всего приложения. В принципе нет смысла пересказывать здесь Java EE 6 Tutorial, лучше расскажу про то, что не понравилось.

Впечатления: несмотря на поразительный шаг вперед по сравнению с предыдущими версиями, некоторые моменты портят впечатление. Во-первых, не понравилось, что в одном месте нельзя вывести сообщение об ошибках, произошедших в нескольких компонентах. Либо выводи вообще все сообщения об ошибках на странице, либо все сообщения для одного компонента. Возможности вывести все первые сообщения об ошибках нескольких компонентов в одном месте нет. Во-вторых, в XXI-м веке то можно корректно обрабатывать HTML-код в сособщениях об ошибках ( ). Если я в своем messages.properties завожу сообщение об ошибке, содержащее разметку, то в браузере данная разметка отображается как есть, т.е. JSF ее экранирует.

Методы authenticate(), login() и logout() в Servlet API

Нововведение конечно не такое масштабное, как JSF 2, но тоже полезное. Особенно, если вы реализуете аутентификацию в вашем веб-приложении посредством стандартных механизмов Java EE. Теперь можно не только настроить FORM-BASED аутентификацию со специальной страницей, содержащей форму логина, но и встроить данную форму в ваше приложение на нужное место. Например, в верхний правый угол каждой страницы. При этом, при нажатии кнопки login, можно самому обработать процесс аутентификации, например посредством AJAX. Так же теперь (всего-лишь в третьей версии Servlet API!) появился стандартный механизм, позволяющий реализовать выход из приложения.

Выводы

Нельзя не отметить, что с каждой новой версией Java EE становится все более и более удобной для разработки. От монструозного детища с EJB 2.0, когда для запуска компонента необходимо было написать два интерфейса, один класс и дескриптор развертывания, не осталось и следа. Java EE 5 была прорывом, Java EE 6 тоже есть чем похвастаться. Это конечно же гораздо больше, чем недавнее изменение пространств имен в дескрипторах развертывания. Хотя есть еще куда развиваться.

Если перед вами стоит задача выбора технологии для нового проекта и есть возможность использовать качественный промышленный сервер приложений, то посмотрите в сторону Java EE. Здесь есть все для удобной и легкой разработки корпоративного приложения. Может быть не стоит тянуть за собой Spring Framework, увеличивая объем поставляемых с приложением библиотек, а значит и время его развертывания. К тому же завязываться на одного поставщика ПО — не лучшая идея.

Буду благодарен, если вы поделитесь своими впечатлениями от использования Java EE в вашем приложении. Особенно интересны проблемы, с которыми столкнулись на продуктиве. Может быть вы уже во всю запускаете что-то на Java EE 7?

Введение в Java EE

Что такое Java EE

Java EE или Java Enterprise Edition представляет платформу для создания корпоративных приложений на языке Java. Прежде всего это сфера веб-приложений и веб-сервисов.

Java EE состоит из набора API и среды выполнения. Некоторые из API:

Java Servlets . Сервлеты представляют специальные модули, которые обрабатывают запросы от пользователей и отправляют результат обработки.

JavaServer Pages (JSP) . Также модули на стороне сервера, которые обрабатывают запросы. Удобны для генерации большого контента HTML. По сути предствляют собой страницы с кодом HTML/JavaScript/CSS с вкраплениями кода на Java

Enterprise JavaBeans (EJB) представляют классы, которые хранят бизнес-логику.

Contexts and Dependency Injection (CDI) предоставляет механизм для внедрения и управления зависимостями в другие объекты.

JSON Processing (JSON-P) позволяет работать со строками JSON в Java

JSON Binding (JSON-B) предоставляет функционал для сериализации и десериализации JSON в объекты Java.

WebSocket позволяет интегрировать WebSocket в приложения на Java.

Java Message Service (JMS) — API для пересылки сообщений между двумя и более клиентами.

Security API — API для стандартизации и упрощения задач обеспечения безопасности в приложениях на Java.

Java API for RESTful Web Services (JAX-RS) — API для применения архитектуры REST в приложениях.

JavaServer Faces (JSF) предоставляет возможности для создания пользовательского интерфейса на стороне сервера.

Эти и ряд других API сообственно и образуют то, что называется Java EE. Стоит отметить, что также в среде веб-разработки на Java популярна еще одна технология Spring. Фреймворк Spring не является частью Java EE и может использоваться как альтернативный подход к созданию веб-приложений на языке Java.

История развития

Предтечей Java EE был проект JPE Project, который стартовал в мае 1998 года. А в декабре 1999 года вышел релиз платформы Enterprise Java Platform (J2EE 1.2), которая объединяла такие компоненты как сервлеты, JSP, EJB, JMS. В 2006 году с выходом 5-й версии она была переименована в Java Enterprise Edition (JEE). С тех пор периодически выходят новые версии платформы. Последняя текущая версия — Java EE 8 вышла в сентябре 2020 года.

В 2020 году произошла новая веха в развитии платформы: Oracle передал контроль над развитием Java EE организации Eclipse Foundation. А в апреле 2020 года Java EE была переименована в Jakarta EE .

Цукерберг рекомендует:  Экспериментируем с CSS функцией element()

В начале 2020 года ожидается выход новой версии Jakarta/Java EE.

Официальный сайт платформы https://jakarta.ee/.

Установка IDE

Для работы с Java EE нам потребуется среда разработки или IDE. Есть различные среды разработки, которые ориентированы на корпоративную разрабоку под Java. Это IntelliJ IDEA, NetBeans и Eclipse. В данном случае на протяжении всего руководства мы преимущественно будем использовать Eclipse, потому что она является бесплатной и довольно широко распространена.

Для начала установим последнюю версию Eclipse, которую можно найти по адресу https://www.eclipse.org/downloads/. На странице загрузок выберем найдем рядом с названием текущей версии Eclipse кнопку «Download» и нажмем на нее.

После нажатия на кнопку нас перенаправит собственно на страницу загрузки, где необходимо будет нажать на кнопку «Download» для загрзуки установочного пакета:

После ее загрузки программы установки запустим ее и в отобразившемся списке опций выберем Eclipse IDE for Java EE Developers :


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

Что такое Java EE?

Изучаю Java SE для применения вебе. Вот никак не могу понять, что за Enterprise Edition. C SE все понятно — набор разных библиотек, которые поставляются с джавой, компилятор там и все подобное.

Но Java EE — это какая-то загадка. Википедия говорит, что Java EE — это Java SE с очень хорошей спецификаций, способностью к масштабированию и все такое прочее. Но что действительно это значит ? Разве у SE плохая спецификация ?

В описании «для чайников» говорится, что Java EE — это Java SE с динамически меняющимися библиотеками. Это как ? Если имеется ввиду обновление, то и на SE есть Maven и все такое, зачем тогда EE ?

Еще часто говорят, что Java EE нужен для серверных разработок. Но зачем ? Сервлеты без проблем можно клепать и на Java SE. Для использования backend-сервера можно воспользоваться библиотекой Jetty. И все это SE.

Лично мне пока вообще не понятно, что происходит в мире Java EE. Может кто-нибудь привести пример использования или написать, чем EE действительно может помочь ?

2 ответа 2

Что-то вы не то прочитали в википедии, или не так поняли. Википедия не говорит, что Java EE это Java SE.

Java EE — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий. https://ru.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

Да, если вы напишите сервер на Jetty, это будет не Java EE (это будет чать Java EE начиная с 7-ой версии Jetty). Но Java EE это не одни сервлеты, туда входит JSP, EJB, CDI, JPA и куча других спецификаций (см. ссылку на википедию).

На практике, J2EE это базовый набор интерфейсов/классов/аннотаций, а уже имплементации предоставляют сервера приложений — WildFly, GlassFish, WebSphere и другие.

Разве у SE плохая спецификация ?

Не плохая, это разные спецификации.

В описании «для чайников» говорится, что Java EE — это Java SE с динамически меняющимися библиотеками.

Но зачем ? Сервлеты без проблем можно клепать и на Java SE. Для использования backend-сервера можно воспользоваться библиотекой Jetty.

Jetty это контейнер сервлетов, это грубо говоря реализация части J2EE (с 7-ой вресии поддерживает Servlet 2.5 API, с 8-ой 3.0). Также как, например, Weld одна из реализаций CDI. Вы это всё можете использовать по отдельности, можете все вместе. Можете взять N технологий J2EE и связать самостоятельно, получится кривенький-косенький сервер приложений. Хотя лучше всё таки взять готовый )

И Jetty это SE, и другие фреймворки это SE, да и половина классов Java это тоже SE. Если есть желание, можете всё с нуля писать.

Лично мне пока вообще не понятно, что происходит в мире Java EE.

Советую прочитать от и до хотя бы одну книгу по J2EE.

Может кто-нибудь привести пример использования или написать, чем EE действительно может помочь ?

Каждая спецификация из J2EE вам чем-то помогает, вы можете использовать их по отдельности или в комплексе, в зависимости от ваших задач. Например: CDI — удобная инъекция зависимостей, не нужно писать кучу лишнего кода или модулей для Guice, JPA — удобная работа с БД на уровне объектов, EJB — удобное написание бизнес логики, JAX-WS — поддержка веб-сервисов, сервлеты — обработка HTTP запросов и т.д. Разрешите одному программисту использовать только Java SE, а второму Java EE и посмотрите за сколько они решат какую-нибудь задачу связанную с веб.

Java EE 5: Мощь и производительность при меньшей сложности

Обзор возможностей Java EE 5 и улучшений, увеличивающих производительность разработчика

Технология Java EE является расширением языковой платформы Java, которое позволяет создавать масштабируемые, мощные и переносимые корпоративные приложения. В ней определено четыре типа контейнеров для компонентов приложения: Web, Enterprise JavaBean (EJB), клиентские приложения и аплеты. Эти контейнеры и поддерживаемые ими Java API подробно описаны в спецификации сервера приложений, что создает и поддерживает конкуренцию на рынке продуктов Java EE, гарантируя при этом серверную переносимость для приложений, которые придерживаются спецификации (см. врезку Краткая история Java EE).

Последняя версия платформы, Java EE 5, была выпущена в мае 2006 года. Сосредоточенная в первую очередь на производительности разработчика, Java EE 5 предоставляет простую модель программирования без ущерба для мощности и функциональности платформы. Упрощение моделей разработки обеспечивают по большей части два механизма — аннотации Java и разумные значения по умолчанию. Важнейшие функциональные усовершенствования включают расширение поддержки Web-сервисов, а также включение в платформу JavaServer Faces (JSF) и стандартной библиотеки тегов Java (JSTL — Java Standard Tag Library).

Краткая история Java EE

Java EE 5 была выпущена Сообществом разработчиков Java (Java Community Process) в виде «зонтичного» JSR (Java Specification Request), который, в свою очередь ссылается на другие спецификации, детально описывающие составляющие технологии (см. раздел Ресурсы). Ведущим разработчиком спецификации является Билл Шеннон из Sun Microsystems, руководящий экспертной группой из 31 человека, включающей как представителей крупнейших ИТ-компаний, так и индивидуальных экспертов. Предшественниками Java EE 5 были:

  • J2EE 1.2 (выпущена в декабре 1999 года): первая версия J2EE, вышедшая вслед за Java 2 Standard Edition (J2SE). В нее входили 10 спецификаций и API, представляющих общий Web-уровень, бизнес-логику, слой хранения данных и службу сообщений, необходимые для корпоративных приложений.
  • J2EE 1.3 (выпущена в сентябре 2001 года): Выпущена как JSR 28. В этой версии усовершенствованы примерно половина спецификаций версии J2EE 1.2 и добавлены XML API, архитектура коннекторов (JCA) и инфраструктура безопасности.
  • J2EE 1.4 (выпущена в ноябре 2003 года): В этой версии усовершенствовано 9 из 13 технологий, которые присутствуют в J2EE 1.3, и включена новая поддержка Web-сервисов и безопасности.

Java EE 5 является следующей версией после J2EE 1.4, потому что в Sun было решено убрать из названия цифру 2 (оставшуюся с тех времен, когда Java 1.2 была переименована в «Java 2»), и теперь используется слово «Java» вместо «J» в сокращенном названии технологии. Стандартное издание (Standard Edition) сейчас называется Java SE 6 (а не J2SE 1.6), а Enterprise Edition называется Java EE 5 (а не J2EE 1.5).

В данной статье рассматриваются возможности Java EE 5 и освещаются изменения, произошедшие со времени последнего релиза J2EE. (Здесь не рассматриваются такие нововведения, как StAX API — API для анализа XML с предварительной загрузкой, и некоторые мелкие или средние улучшения во многих API.) В статье приводится комплексный обзор четырех основных категорий: Web-сервисы, Web-приложения, корпоративные приложения, управление и безопасность. Также, кроме теории, в статье рассматривается небольшое приложение, которое использует возможности Java EE 5 и демонстрирует простоту модели разработки Web-приложений, которые используют сервис-ориентированную архитектуру (SOA).

Эта статья предназначена для читателей, знакомых с программными корпоративными системами, которые хотят всесторонне, на высоком уровне рассмотреть Java EE 5. Для обзора возможностей платформы знания языка программирования Java и J2EE будут полезны, но не обязательны. При обсуждении примера приложения мы углубляемся в технические детали, которые, вероятно, будут более актуальными для тех, кто уже знаком с внутренностями J2EE (или по крайней мере с программированием на Java).

Технологии Web-сервисов

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

Прорыв в поддержке Web-сервисов

Краеугольным камнем в поддержке Web-сервисов в Java EE 5 является JAX-WS 2.0, представляющий собой дополнение к JAX-RPC 1.1. Обе эти технологии позволяют создавать Web-сервисы, основанные на архитектурах REST или SOAP, без непосредственной утомительной обработки XML и привязки данных, необходимых для Web-сервисов. Разработчики могут свободно продолжать использовать JAX-RPC (поддержка которого по-прежнему обязательна для Java EE 5 контейнеров), однако настоятельно рекомендуется перейти на JAX-WS. Новички в Web-сервисах могут не изучать JAX-RPC, а сразу сосредоточиться на JAX-WS. Тем не менее стоит помнить, что оба они поддерживают SOAP 1.1 через HTTP 1.1 и полностью совместимы: клиент Web-сервиса JAX-WS может получить доступ к конечной точке Web-сервиса JAX-RPC, и наоборот.

JAX-WS обладает убедительным преимуществами перед JAX-RPC, а именно:

  • Поддерживает стандарт SOAP 1.2 (в дополнение к SOAP 1.1).
  • Поддерживает XML поверх HTTP. При желании можно обойтись вообще без SOAP (более подробно см. статью «Use XML directly over HTTP for Web services (where appropriate)»).
  • Использует архитектуру Java Architecture for XML Binding (JAXB) для привязки данных к модели. JAXB полностью поддерживает XML Schema и имеет высокую производительность (об этом будет рассказано далее).
  • Вводит модель динамического программирования для сервера и клиента. Модель клиента поддерживает подход, использующий сообщения, и асинхронный подход.
  • Поддерживает механизм оптимизации передачи сообщений (MTOM — Message Transmission Optimization Mechanism). MTOM рекомендован W3C для оптимизации передачи и формата SOAP-сообщений.
  • Предоставляет усовершенствованную поддержку кросс-платформенного взаимодействия Web-сервисов (WS-I — Web services interoperability). (Поддерживается Basic Profile 1.1; JAX-WS поддерживает только Basic Profile 1.0.).
  • Предоставляет усовершенствованную поддержку вложений SOAP. (Используется SOAP with Attachments API for Java [SAAJ] 1.3; JAX-WS поддерживает только SAAJ 1.2.).

Узнать больше о различиях можно из статьи «JAX-RPC versus JAX-WS».

Инструмент wsimport в JAX-WS автоматически берет на себя многие детали разработки Web-сервиса и легко встраивается в процесс сборки на любой платформе, позволяя разработчику сосредоточиться на реализации логики приложения, которое реализует или использует службу. Он генерирует такие артефакты, как сервисы, интерфейсы конечной точки сервисов (SEI), код для асинхронного ответа, исключительные ситуации, основанные на ошибках WSDL, а также классы Java, привязанные к типам схемы с помощью JAXB.

JAX-WS также позволяет создавать высокопроизводительные Web-сервисы. См. статью «Implementing High Performance Web Services Using JAX-WS 2.0» в разделе Ресурсы, которая представляет сравнительное исследование эквивалентных реализаций Web-сервисов, основанных на новом стеке JAX-WS (который использует две другие возможности Java EE 5 для Web-сервисов- JAXB и StAX) и стеке JAX-RPC, включенном в J2EE 1.4. В ходе исследования было установлено, что с JAX-WS увеличение производительности составляет от 40% до 1000% в зависимости от функциональной области и нагрузки.

Технологии Web-приложений

В Java EE 5 к технологиям для разработки внешнего интерфейса Web-приложений вдобавок к существующим спецификациям JavaServer Pages и Servlet были добавлены два важных фрагмента — JSF и JSTL. JSF представляет собой набор программных интерфейсов (API), которые позволяют применять компонентно-ориентированный подход при разработке пользовательских интерфейсов. JSTL — это набор библиотек тегов, которые поддерживают встраивание процедурной логики, доступ к JavaBeans и командам SQL, локализованные инструкции форматирования, а также обработку XML в JSP. Самые последние версии JSF, JSTL и JSP поддерживают единый язык выражений (EL), что позволяет легко интегрировать эти технологии (см. раздел «Ресурсы»).

JSF 1.2

JSF имеет встроенную поддержку для решения общих проблем построения пользовательского интерфейса, таких как управление состоянием компонента, обработка событий, навигация, валидация пользовательского ввода, интернационализация. Опытные разработчики могут создавать собственные мощные и многократно используемые компоненты и правила отображения для клиентских устройств, отличающихся от Web-браузера. Менее технически подкованные пользователи могут повторно использовать пользовательские компоненты, включенные по умолчанию в библиотеку тегов JSF для интерфейсов HTML, в визуальных средах программирования, таких как Sun Java Studio Creator. Это позволяет начинающим программистам создавать современные Web-интерфейсы.

Появляется все больше компонентов JSF, написанных сторонними разработчиками, как сообществами Open Source, так и представителями индустрии лицензионного программного обеспечения. В Интернете можно найти множество библиотек, поискав по запросам «JSF components» или «JSF component libraries». Многие из этих компонентов работают с технологией Asynchronous JavaScript + XML (AJAX), которая является движущей силой Web 2.0-подхода. Web-программисты могут использовать их для создания приложений с более широкими возможностями, чем у традиционных Web-приложений, избегая при этом лишней работы по написанию Ajax-компонентов с нуля.

JSP 2.1

Технология JSP входит в состав J2EE с версии 1.2. Она расширяет спецификацию Java Servlet возможностями декларативного программирования пользовательских интерфейсов. JSP предоставляет поддержку программирования пользовательских интерфейсов как документов, которые транслируются в Java-сервлеты, компилируются и вызываются контейнером Web-приложения для обработки запросов. Эти документы, как правило, сочетают в себе директивы JSP и скриптлеты с языком разметки, таким как HTML. В JSP-документах можно использовать старый синтаксис, который основан на специальных тегах, начинающихся с и заканчивающихся %> , или новый синтаксис — корректно сформированный XML. Они, как правило, выступают как часть «Вид» в UI-каркасах, основанных на шаблоне «модель-вид-контроллер» (MVC).

JSP 2.1 и JSF 1.2 более совместимы между собой, чем предыдущие версии, в первую очередь благодаря интеграции синтаксиса их языков выражений в унифицированный EL. Этот EL позволяет выполнять такие операции, как:

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

В прошлом существовали различия между в синтаксисе EL в JSP и JSF и в том, как контейнеры обрабатывали их. Унифицированный EL устраняет эти различия, а также добавляет такие функции, как:

  • Модифицируемый каркас для настройки интерпретации EL.
  • Поддержка отложенных выражений, которые могут выполняться по мере необходимости обработчиком JSP-тегов.
  • Поддержка операций присваивания, которые могут, например, использовать выражения EL для установки значения свойства JavaBean-компонента из кода JSP.

Большим подарком для разработчиков библиотек JSP-тегов является поддержка подключения ресурсов в обработчики тегов с помощью аннотаций. Это позволяет значительно упростить теги, которые раньше требовали конфигурирования ресурсов и кода для выполнения поиска в JNDI.

JSTL 1.2

Технология JSTL существует уже давно, но до Java EE 5, она располагалась вне «зонта» Java EE. Теги JSTL предоставляют поддержку встраивания в JSP элементов следующих типов:

  • Процедурная логика, такая как циклы и переключатели if / else .
  • Доступ к JavaBean-компонентам, которые могут предоставлять динамические данные пользовательскому интерфейсу или изменять код пользовательского интерфейса.
  • Команды SQL для доступа к базам данных.
  • Инструкции форматирования, которые форматируют вывод пользовательского интерфейса в соответствии с конкретными локалями.
  • Обработка XML, например, анализ согласно DOM (Document Object Model — объектная модель документа) или XSL-преобразования (Extensible Stylesheet Language — расширяемый язык таблиц стилей).

Версия JSTL 1.2 поддерживает унифицированный EL, что решает проблемы, возникавшие при попытках смешать теги JSF и теги JSTL для выполнения итераций на одной JSP-странице.

Java Servlet 2.5

Спецификация Java Servlet — основа технологий Web-уровня в Java — стара как сама технология Java EE. Ее задача — предоставить высокопроизводительный компонентный подход к созданию Web-приложений, которые можно перенести на любой сервер, реализующий спецификацию.

Спецификация Servlet 2.5, обязательно поддерживаемая в Java EE 5, включает незначительные улучшения по сравнению с версией 2.4. Она вводит зависимость от платформы Java 5, а также ряд аннотаций, которые уменьшают необходимость в конфигурировании через конфигурационный файл дескриптора развертывания Web-приложений (web.xml). Также внесены дополнительные улучшения в конфигурирование, например, более гибкое конфигурирование сервлетов с помощью шаблонов и множественных элементов url-pattern .

Технологии корпоративных приложений

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

EJB 3.0

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

EJB делятся на 3 основных типа:

  • Session Beans (сеансовые компоненты) — эти компоненты бывают двух видов: не запоминающие свое состояние (stateless) и запоминающие свое состояние (stateful). Stateless EJB-компоненты используются для решения задач бизнес-логики и обслуживают одиночные запросы из клиентского кода. Stateful EJB-компоненты помнят о состоянии «диалога» с клиентом и удобны для решения наборов взаимосвязанных задач, которые охватывают множество клиентских запросов. Сеансовые EJB-компоненты не могут использоваться клиентами совместно. Они, как правило, управляют одним или несколькими Entity-компонентами.
  • Entity Beans (компоненты, представляющие сущности) представляют собой данные длительного хранения, которые обычно загружаются из базы данных. Entity-компоненты могут использоваться пользователями совместно, а спецификация EJB предусматривает транзакционно-безопасный механизм, который обеспечивает обработку множества одновременных клиентских запросов без опасности повреждения данных. Entity-компонент может сам управлять своей синхронизацией с базой данных или позволить управлять ею контейнеру (управляемая контейнером синхронизация — container managed persistence, CMP).
  • Message-driven Beans (компоненты, управляемые сообщениями) обрабатывают клиентские запросы, не заставляя клиента ждать ответа. Они, как правило, взаимодействуют с очередями Java Message Service (JMS) — еще одна технология корпоративных приложений в Java EE 5, — но также обслуживают асинхронных клиентов, даже тех, которые не написаны на Java.

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

EJB 3.0 предоставляет значительные улучшения в модели программирования EJB и является одним из крупнейших потенциальных источников повышения производительности для разработчиков Java EE 5. Теперь EJB-компонент может быть аннотированным простым Java-объектом (POJO — Plain Old Java Object), который не обязан наследовать определенным классам. Он только должен реализовать удаленный (remote) интерфейс, который можно определить самостоятельно или поручить его автоматическое создание IDE-среде. Дескрипторы развертывания больше не требуются, поскольку EJB-контейнер может извлечь все, что ему необходимо знать, из аннотаций.

В этой статье в разделе «Пример приложения: The RideSynergy» представлен пример кода, в котором содержатся конкретные примеры таких усовершенствований. Читатели, жаждущие более глубоких подробностей, смогут найти в разделе «Ресурсы» ссылки на две статьи, которые дают убедительные примеры того, насколько улучшились EJB в последней версии.


Java Persistence API (JPA 1.0)

JPA — это каркас для объектно-реляционного преобразования (ORM — object-relational mapping) для сохранения Java-объектов в реляционных СУБД. Он был разработан специально для использования с EJB, но может использоваться и для любых других объектов Java. Используя аннотации, можно указать, какие объекты и поля будут сохраняться и к каким таблицам и столбцам базы данных их необходимо прикрепить. JPA поддерживает богатый язык запросов, похожий на SQL. Язык запросов позволяет:

  • Определять параметры запросов в виде списков: упорядоченного (обращение к элементам по индексу) или именованного (обращение по именам параметров).
  • Определять запросы для установления отношений между постоянными сущностями без использования конструкции JOIN (хотя при желании можно использовать и такую конструкцию).
  • Применять обычные SQL-подобные средства в критериях поиска (операторы сравнения, операция LIKE , операция BETWEEN и т.д.) и определять, каким образом обрабатывать результирующее множество (с помощью таких операторов, как DISTINCT , ORDER BY , GROUP BY и т.д.)

JPA вносит новые функциональные возможности в платформу Java EE, избавляя разработчиков от головной боли, которая возникала при работе с самодельными средствами сохранения объектов или применении подходов, зависимых от контейнера. Статья «Design enterprise applications with the EJB 3.0 Java Persistence API» является хорошей отправной точкой для более глубокого изучения этой темы.

Управление и безопасность

Java EE 5 требует все тех же трех спецификаций безопасности и управления, которые были доступны в предыдущих версиях:

  • Развертывание приложения (Application Deployment) предоставляет API для развертывания компонентов и приложений в контейнер Java EE. Инструменты могут получить доступ к этому API при развертывании кода в контейнер Java EE 5 без перезагрузки контейнера. Интегрированные среды разработки часто используют этот API, который позволяет быстро выполнять цикл кодирование/тестирование/исправление в процессе разработки.
  • Управление приложением (Application Management) определяет необходимые атрибуты и операции объектов, управляемых контейнером. Этот API совместим с различными стандартными отраслевыми протоколами управления.
  • Соглашение об авторизации для контейнеров (Java ACC, Authorization Contract for Containers) определяет семантику провайдеров безопасности и то, как авторизовать доступ к операциям управления с учетом этого соглашения. Это соглашение требует, чтобы контейнеры реализовывали интерфейсы, позволяющие использовать инструменты развертывания для управления ролями, использующимися для авторизации.

Каждая из этих спецификаций в Java EE 5 представляет собой обновления (с версии 1.0, введенной в J2EE 1.4, до версии 1.1) с минимальными изменениями, которые слишком подробны для этой статьи. В разделе Ресурсы приведены ссылки для получения более подробной информации о технологиях управления и безопасности в Java EE.

Пример приложения: The RideSynergy

В этом разделе приводится несколько примеров упрощенных моделей программирования в Java EE 5, помогающих повысить производительность разработчика. Из примеров можно увидеть, как эти модели позволяют быстро разработать приложение, содержащее конечную точку для Web-сервиса и клиент, используя EJB для бизнес-логики и JSF для разработки Web-интерфейса.

Java EE 5 на WAS CE 2.0

WebSphere® Application Server, Community Edition (WAS CE) версия 2.0 сертифицирована для Java EE 5. По этой ссылке можно узнать больше о WAS CE и скачать его бесплатно.

Ниже будет продемонстрировано применение технологий Java EE 5 на примере разработки простого Web-приложения для воображаемой службы RideSynergy (примеры кода см. в разделе Материалы для скачивания). RideSynergy помогает людям встречаться в сети и договариваться о совместном использовании автомобилей. (Концепция совместного использования автомобилей (carpooling) широко распространена в странах, где принято добираться на работу на личном автомобиле. Люди, живущие неподалёку, договариваются поочерёдно по пути на работу заезжать друг за другом, и, соответственно, по пути с работы развозить коллег по домам.) Приложение разработано с использованием NetBeans 5.5 и проверено на Sun Application Server 9.0_01 и WebSphere Application Server (Community Edition) 2.0.

RideSynergy работает следующим образом:

  • Принимает заявки на поездки и предложения через Web-страницу.
  • Если пользователь делает предложение о поездке, приложение отображает список заявок.
  • Если пользователь запрашивает поездку, то приложение отображает список подходящих предложений подвезти.
  • Для удобства пользователя приложение дает возможность посмотреть погоду на маршруте следования, так как погодные условия могут повлиять на решение пользователя о планируемой поездке.
  • Приложение предоставляет статистику заявок и предложений в виде Web-сервиса для использования в приложениях сторонних разработчиков.

Посетитель RideSynergy использует страницу, показанную на рисунке 1, для ввода предложения или запроса поездки, определения ZIP-кода (почтового индекса) места отправления и места назначения и ввода адреса электронной почты. Эта страница также дает возможность увидеть отчет о погоде в указанной местности.

Рисунок 1. Страница для запроса и предложения поездки R >Кликните, чтобы увидеть увеличенное изображение

Если пользователь ввел предложение о поездке, то на странице результатов (см. рисунок 2) отобразится список соответствующих ему запросов на поездку. Если введен запрос на поездку, то в списке будут соответствующие предложения. Прогноз погоды появляется только в том случае, если установлен флажок Check Weather (Проверять погоду) на странице заявок и предложений. (Заметьте, что в реальном приложении отображается прогноз погоды на пять дней, а рисунок 2 для краткости обрезан.) Данные для отчета о погоде извлекаются из общедоступных Web-сервисов, таких как http://www.webservicex.net.

Рисунок 2. Страница результатов R >Кликните, чтобы увидеть увеличенное изображение

Код, используемый в RideSynergy, демонстрирует простоту модели программирования Web-сервисов в Java EE 5: для определения конечной точки Web-сервиса используется JAX-WS с аннотацией, а клиент Web-сервиса создается с помощью утилиты wsimport . Также этот код демонстрирует основы JSF и то, насколько проста модель программирования EJB в Java EE 5.

Аннотации: больше работы с помощью меньшего количества кода

Функция RideSynergy, которая предоставляет статистику поездок в виде Web-сервиса, является убедительным примером того, как Java EE 5 позволяет делать больше работы с помощью меньшего количества кода. Эта функция реализована в классе RideStatistics , который демонстрирует аннотации Java EE 5 в их простейшем виде. Не стоит думать, что простота здесь достигается за счет потери мощности: этот пример показывает, насколько менее сложным является подход Java EE 5 к реализации этих возможностей по сравнению с J2EE 1.4.

Класс RideStatistics в листинге 1 реализует Web-сервис, который использует Stateless EJB-компонент RideManagerBean для просмотра количества предложений поездок, сделанных пользователями RideSynergy между пунктами с ZIP-кодами, определенными клиентом Web-сервиса. Интерфейс RideManagerRemote определяет методы RideManagerBean , которые доступны из клиентского кода вне зависимости от того, выполняется он на той же самой JVM или нет.

Листинг 1. Web-сервис R >

Листинг 1 содержит две аннотации: @WebService и @EJB . Сначала рассмотрим, каким образом аннотация @EJB реализует прием dependency injection (подключение компонентов, от которых зависит наш компонент) для доступа к EJB-компонентам. Далее будет показано, как аннотация @WebService позволяет сделать POJO полноправной конечной точкой Web-сервиса.

Подключение необходимых компонентов

Читатель, знакомый с программированием EJB в J2EE 1.4, может посмотреть на листинг 1 и спросить: «действительно ли так просто получить ссылку на EJB?». Дело в том, что аннотация @EJB позволяет упростить модель программирования, основанную на подключении (инъекции) компонентов, необходимых для функционирования Web-сервисы.

Аннотация @EJB устраняет необходимость писать код, который в J2EE 1.4 выглядел бы похоже на приведенный в листинге 2:

Листинг 2: Клиент R >

В модели программирования EJB 3.0, поддерживаемой Java EE 5, аннотация @EJB означает, что нужно подключить зависимость RideStatistics от RideManagerRemote , а не требовать, чтобы RideStatistics нашел ссылку, используя JNDI.

Это также устраняет необходимость прямой зависимости от пакета, в котором находится RideManagerRemote . Обратите внимание на выражения import ; здесь не импортируется RideManagerRemote (и да, это компилируется!). В результате можно выполнить рефакторинг с переносом RideManagerRemote в другой пакет, и это не приведет к необходимости обновлять и перекомпилировать RideStatistics .

Аннотации также дают множество преимуществ с другой стороны рассматриваемой зависимости: со стороны EJB-компонента, который представляет реализацию RideManagerRemote и указывает контейнеру Java EE 5, что с ним делать. Это будет рассмотрено ниже.

Сложное поведение во время выполнения

При развертывании в контейнере Java EE 5 аннотация @WebService в листинге 1 обрабатывается с помощью JAX-WS и превращает класс RideStatistics в полноценную конечную точку Web-сервиса с двумя операциями: rideOffersFromZipCode и rideOffersFromToZipCode . JAX-WS обрабатывает все технические детали, необходимые для предоставления Web-сервиса, в том числе генерацию WSDL-документа (Web Services Description Language — язык описания Web-сервисов), что позволяет другим приложениям в Web находить и использовать этот Web-сервис, а также обрабатывает механику ответов на запросы клиента к Web-сервису.

Цукерберг рекомендует:  Как работает Java garbage collector (сборщик мусора)

По умолчанию WSDL, который определяет JAX-WS для службы RideStatistics, располагается по адресу: http://server:port/ridesynergy2-war/RideStatisticsService?WSDL. Для просмотра этого WSDL-документа нужно:

  1. Скачать enterprise-архив приложения RideSynergy, ridesynergy2.ear (см. раздел «Материалы для скачивания») и развернуть его в контейнере Java EE 5.
  2. Заменить значения server и port в расположении по умолчанию на имя хоста и порт используемого контейнера.
  3. Открыть полученный URL-адрес в браузере.

Более сложные аннотации

Аннотации в листинге 1 представляют собой простые аннотации. Аннотации также могут принимать именованные параметры (named elements), которые схожи с параметрами метода, за исключением того, что порядок и количество параметров не имеют никакого значения, поскольку каждый из них именован. Использование именованных параметров похоже на передачу в аннотацию таблицы с ключами (map), которая содержит пары ключ/значение, влияющие на обработку аннотации.

Интерфейс WeatherForecastSoap (показанный в листинге 3), который был создан инструментом wsimport в JAX-WS, содержит аннотации, принимающие именованные параметры. В листинге 3 приведен код интерфейса WeatherForecastSoap:

Listing 3: Интерфейс WeatherForecastSoap

В листинге 3 указана аннотация @WebMethod для метода getWeatherByZipCode() , которая состоит из двух именованных элементов: operationName и action . Этот пример также содержит аннотацию @WebParam для параметра zipCode метода getWeatherByZipCode() с именованными элементами name и targetNamespace . (Заметьте, что в реальном приложении метод getWeatherByZipCode() имеет и другие аннотации, но здесь они опущены для краткости.)

Получить более подробную информацию об аннотациях можно по ссылке Annotations в разделе «Ресурсы».

Объявление stateless сеансового EJB-компонента

В листинге 4 показано объявление класса RideManagerBean — stateless сеансового EJB-компонента, который реализует интерфейс RideManagerRemote , используемый в листинге 1:

Листинг 4: Объявление stateless session EJB-компонента

В J2EE 1.4 этому EJB пришлось бы реализовать интерфейс SessionBean , требующий реализации шести методов. Во многих случаях реализация этих методов остается пустой и существует лишь для соответствия интерфейсу и возможности компиляции кода, что засоряет код. В EJB 3.0 с этой проблемой покончено путем предоставления аннотаций жизненного цикла @PostConstruct , @PreDestroy , @PostActivate и @PrePassivate . Эти аннотации можно добавлять по мере необходимости к любому public-методу без параметров и с возвращаемым типом void для реагирования на события жизненного цикла.

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

Аннотации в Java EE 5 также устраняют большой объем конфигурационного кода, который был необходим в ранних версиях Java EE. Например, аннотация @Stateless в листинге 4 устраняет необходимость в дескрипторе развертывания EJB, который представляет собой конфигурационный XML-файл, предоставляющий контейнеру подробную информацию о EJB-компоненте. В предыдущих платформах Java EE такой дескриптор представлял собой XML-файл, соответствующий схеме EJB 2.1. Часть конфигурации RideManagerBean и необходимых для него интерфейсов выглядела бы так, как показано в Листинге 5:

Листинг 5: Дескриптор развертывания в версиях до Java EE 5

Java EE 5 имеет обратную совместимость с дескрипторами развертывания EJB. Можно даже сочетать подходы, продолжая в унаследованном коде использовать дескрипторы развертывания EJB, а новые EJB-компоненты объявлять с аннотациями.

Помимо сокращения количества кода, аннотации позволяют воспользоваться тем, что архитектор Sun Грэм Гамильтон называет «truth-in-source-code» (см. раздел «Ресурсы»): в надлежащем образом аннотированном классе не нужно одновременно смотреть на исходный код и конфигурационные файлы, чтобы понять, что происходит, потому что аннотации, определяющие поведение, находятся прямо в коде.

Для изучения других примеров того, как аннотации облегчают разработку приложений на Java EE 5, рекомендуется статья Роланда Барсии «Get to know Java EE 5».

Разумные значения по умолчанию

Тот факт, что RideStatistics можно сделать Web-сервисом, просто добавив одну аннотацию, также иллюстрирует другой принцип проектирования Java EE 5: упрощение модели программирования за счет разумных умолчаний.

В данном случае JAX-WS предполагает, что любой общедоступный метод в классе с аннотацией @WebService должен быть превращен в операцию Web-сервиса с тем же самым именем. Аналогичные предположения делаются при обработке входных и выходных параметров этих методов. Если поведение по умолчанию не подходит, его всегда можно изменить, создав аннотации для методов. Но во многих случаях вам, вероятно, потребуется, чтобы термины, использующиеся в Web-сервисе, соответствовали терминам в классе, который реализует Web-сервис, и JAX-WS легко позволяет это сделать за счет разумных умолчаний.

Заключение

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

Java EE 5 стремится разрушить эту репутацию путем привлечения новых языковых средств, таких как аннотации, принципов проектирования, таких как разумные умолчания, и упрощения моделей программирования. Она предоставляет доступную мощную платформу для разработки корпоративных приложений. Упрощение моделей программирования также делает разработку менее зависимой от сторонних инструментов для борьбы с излишней сложностью. В итоге тем, кто выделяет средства на разработку, становится значительно дешевле разрабатывать все более мощные корпоративные приложения. Выгода для разработчиков состоит в меньших временных затратах на борьбу с платформой, в результате чего остается больше времени на быструю разработку новой функциональности.

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

Ресурсы для скачивания

Похожие темы

  • Java EE 5: Power and productivity with less complexity: оригинал статьи (EN).
  • Разделы Java EE и Java EE APIs & Docs сайта Sun Microsystems: основной источник информации по технологии Java EE, включая Java EE 5 SDK API и предыдущие выпуски (EN).
  • Update: An Introduction to the Java EE 5 Platform (Джон Стернс, Роберто Кинничи и Саху, java.sun.com, май 2006 г.): техническая статья, которая будет полезна разработчикам, изучающим Java EE 5 (EN).
  • Get to know Java EE 5: весьма техническая статья о Java EE 5 с множеством примеров кода (EN).
  • What’s new in WebSphere Application Server Community Edition V2.0 (Ашин Жэйн, developerWorks, сентябрь 2007 г.): статья, знакомящая с WAS CE 2.0 и также содержащая несколько таблиц, в которых сведены отличия между J2EE 1.4 и Java EE 5.
  • Java EE version history (EN): краткая история релизов Java EE и составляющих ее спецификаций в Википедии.
  • Java EE JSRs (EN): все Java EE JSR, поддерживаемые сообществом разработчиков Java.
  • Implementing High Performance Web Services Using JAX-WS 2.0 (EN) (Бхарат Мандлапади, java.sun.com, август 2006 г.): эта статья демонстрирует выигрыш в производительности при реализации Web-сервиса с использованием JAX-WS 2.0 вместо JAX-RPC 1.1.
  • The Simplicity of EJB 3.0 (Раджа Р. Кодали, JDJ, август 2005 г.): в статье сравниваются реализации приложения RosterApp в J2EE 1.4 и Java EE 5 и показывается, насколько проще стала разработка EJB.

  • Ease of Development in Enterprise JavaBeans Technology (EN) (Эд Орт, java.sun.com, октябрь 2004 г.): обзор усовершенствований EJB 3.0.
  • Raving about Java EE (EN) (Грэм Гамильтон, java.net, февраль 2006 г.): блог Гамильтона является источником идеи «истина в исходном коде».
  • Annotations (EN): примеры аннотаций от Sun.
  • Annotations in Tiger, Part 1: Add metadata to Java code, Annotations in Tiger, Part 2: Custom annotations: обзор возможностей встроенных и пользовательских аннотаций, входящих в Java SE 5 (EN).
  • New features added to Servlet 2.5 (EN).
  • Unified Expression Language: статья о новых возможностях унифицированного языка выражений (EN).
  • Java EE Management and Security Technologies: более подробная информация об управлении и безопасности в Java EE (EN).
  • Скачайте WebSphere Application Server Community Edition 2.0 (EN).
  • Скачайте ознакомительные версии продуктов IBM и опробуйте на практике средства для разработки приложений и связующее программное обеспечение DB2®, Lotus®, Rational®, Tivoli® и WebSphere (EN).
  • Раздел Технология Java сайта developerWorks Россия: сотни статей обо всех аспектах Java-программирования.

Комментарии

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

Учебное пособие по J2EE. Обзор

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

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

Это руководство основано на примерах, описывающих возможности и функции, доступные в J2EE SDK версии 1.3. Вне зависимости от того, новичок Вы или опытный корпоративный разработчик, Вы найдете в примерах и сопровождающем их тексте полезную и доступную информацию для создания ваших собственных корпоративных решений.

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

В этой главе

Распределенные многоуровневые приложения

Платформа J2EE использует модель многоуровневого распределенного приложения. Логически приложение разделено на компоненты в соответствии с их функциональностью. Различные компоненты, составляющие J2EE-приложение, установлены на различных компьютерах в зависимости от их уровня в многоуровневой среде J2EE, которой данный компонент принадлежит. На рисунке 1-1 представлены два J2EE-приложения, разделенные на уровни, перечисленные в следующем списке. Части J2EE-приложения, показанные на рисунке 1-1, представлены в разделе «J2EE -компоненты».

Компоненты клиентского уровня работают на клиентской машине.

Компоненты Web-уровня работают на J2EE-сервере.

Компоненты бизнес-уровня работают на J2EE-сервере.

Программное обеспечение уровня корпоративной информационной системы (EIS) работает на EIS-сервере.

Хотя J2EE-приложение состоит из трех или четырех уровней, показанных на рисунке 1, многоуровневые J2EE-приложения обычно принято называть трехуровневыми, т.к. они расположены на трех различных системах: клиентский компьютер, сервер J2EE и сервер базы данных или обычный сервер. Трехуровневые приложения, работающие данным способом, расширяют стандартную архитектуру клиент-сервер, добавляя многопоточный сервер приложений между клиентской частью и сервером базы данных.

Рисунок 1. Многоуровневые приложения

J2EE-компоненты

J2EE-приложения состоят из компонентов. J2EE-компонента представляет собой законченный функциональный программный модуль, встроенный в приложение J2EE с соответствующими классами и файлами и взаимодействующий с другими компонентами. J2EE-спецификация определяет следующие J2EE-компоненты:

Клиентские приложения и апплеты – это компоненты, работающие на клиентской машине.

Компоненты технологии Java-сервлет и JavaServer Pages (JSP) – это Web-компоненты, работающие на сервере.

Корпоративные компоненты – это бизнес-компоненты, работающие на сервере.

J2EE-компоненты пишутся на языке программирования Java и компилируются точно так же, как и любая другая Java-программа. Отличием между J2EE-компонентами и «стандартными» классами Java является то, что J2EE-компоненты собираются в J2EE-приложение, находящееся в строгом соответствии со спецификацией J2EE, развернутое для функционирования в соответствующем месте и управляемое сервером J2EE.

J2EE-клиенты

J2EE-клиентом может быть Web-клиент или клиент приложения.

Web-клиенты

Web-клиент состоит из двух частей: динамические Web-страницы, написанные на языках разметки различного типа (HTML, XML и т.д.), генерируемые Web-компонентами на Web-уровне, и Web-браузер, визуализирующий полученные от сервера страницы.

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

Апплеты

Web-страница, полученная от Web-уровня, может включать в себя встроенный апплет. Апплет — это небольшое клиентское приложение, написанное на языке Java и выполняющееся на установленной в Web-браузере виртуальной машине Java. Однако системы клиента могут потребовать Java- Plug-in и файл политики безопасности для того, чтобы апплет успешно выполнялся в Web-браузере.

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

Клиенты приложения

Клиент J2EE-приложения работает на клиентской машине и обеспечивает пользователей возможностью работать с задачами, требующими более богатого пользовательского интерфейса, чем тот, который предоставлен языками разметки страниц. Они обычно имеют графический пользовательский интерфейс, созданный при помощи Swing или AWT API, хотя, безусловно, возможен и интерфейс командной строки.

Клиенты приложения имеют непосредственный доступ к корпоративным компонентам, исполняющимся на бизнес-уровне. Тем не менее, клиент приложения J2EE может открыть HTTP соединение для коммуникации с сервлетом, работающим на Web-уровне, если существуют такие требования к приложению.

Архитектура компонентов JavaBeans

Уровни сервера и клиента могут также включать компоненты, основанные на архитектуре компонентов JavaBeans, для управления потоком данных между клиентом приложения или апплетом и компонентами, выполняющимися на сервере J2EE, либо компонентами сервера и базой данных. Компоненты JavaBeans не считаются компонентами J2EE согласно спецификации J2EE.

Компоненты JavaBeans содержат переменные экземпляра и методы get и set для доступа к данным в переменных экземпляра. Компоненты JavaBeans, используемые таким образом, обычно просты по дизайну и реализации, но должны быть согласованы с правилами именования и дизайна, определенными в архитектуре компонентов JavaBeans.

Коммуникации сервера J2EE

На рисунке 2 показаны различные компоненты, которые могут составлять клиентский уровень. Клиент связан с выполняющимся на J2EE-сервере бизнес-уровнем либо непосредственно, либо (как в случае с работающим в браузере клиентом) посредством JSP-страниц или сервлетов, работающих на Web-уровне.

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

Рисунок 2. Коммуникации сервера

Web-компоненты

J2EE Web-компоненты могут быть либо сервлетами, либо страницами JSP. Сервлеты — это классы языка Java, которые динамически управляют запросами и конструируют ответы. JSP-страницы являются текстовыми документами, которые исполняются так же, как и сервлеты, но предлагают более естественный подход к созданию статического содержания.

Статические HTML-страницы и апплеты связываются с Web-компонентами во время сборки приложения, но не считаются Web-компонентами по J2EE-спецификации. Обслуживающие классы со стороны сервера также могут быть связаны с Web-компонентами и, подобно HTML-страницам, не считаются Web-компонентами.

Так же как и клиентский уровень, Web-уровень, показанный на рисунке 3, может включать в себя компонент JavaBeans для управления вводом пользователя и направления этого ввода в работающий на бизнес-уровне корпоративный компонент для обработки.

Рисунок 3. Web-уровень и J2EE-приложение

Бизнес-компоненты

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

Рисунок 4. Бизнес- и EIS-уровень

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

Управляемые сообщениями компоненты комбинируют особенности сессионного компонента и JMS (службы сообщений Java) приемника сообщений, позволяя бизнес-компоненту получать сообщения JMS асинхронно. Данное учебное пособие описывает сессионные компоненты и компоненты управления данными. Для информации об управляемых сообщениями компонентах см. «Учебное пособие по службе сообщений Java», доступное на

Уровень корпоративной информационной системы

Уровень корпоративной информационной системы образует программное обеспечение информационной системы и включает в себя системы корпоративной инфраструктуры, такие как планирование ресурсов предприятия (ERP), управление транзакциями мейнфрейма, базы данных, и другие стандартные информационные системы. J2EE-компоненты могут нуждаться в доступе к корпоративным информационным системам для взаимодействия, например, с базами данных.

J2EE-контейнеры

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

Контейнерные сервисы

Контейнеры являются интерфейсом между компонентом и низкоуровневыми платформо-зависимыми функциональными возможностями, поддерживающими компонент. До того, как Web-компонент, корпоративный компонент или компонент клиентского приложения может быть выполнен, он должен быть скомпонован в J2EE-приложение и размещен внутри своего контейнера.

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

Модель безопасности J2EE позволяет сконфигурировать Web-компонент или корпоративный компонент так, что доступ к системным ресурсам разрешается только авторизованным пользователям.

Модель транзакции J2EE позволяет вам определять взаимосвязи между методами, которые составляют простую транзакцию, так, что все методы в одной транзакции интерпретируются как один модуль.

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

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

Тот факт, что J2EE-архитектура обеспечивает конфигурируемые сервисы, означает, что компоненты в J2EE-приложении могут вести себе по-разному, в зависимости от места их размещения. Например, корпоративный компонент может иметь установки безопасности, дающие ему определенный уровень доступа к базе данных в одном рабочем окружении и другой уровень доступа — в другом.

Контейнер также управляет неконфигурируемыми сервисами, такими как время жизни корпоративного компонента и сервлета, ресурсный пул (объединение ресурсов) связи с БД, персистенция данных, доступ к API J2EE-платформы, описанным в разделе «J2EE API». Хотя сохраняемость данных является неконфигурируемым сервисом, J2EE-архитектура позволяет замещать сохраняемость, управляемую контейнером, при помощи включения соответствующего кода в реализацию вашего корпоративного компонента в тех случаях, когда вы желаете получить больший контроль, чем обеспечиваемый по умолчанию. Например, Вы можете использовать персистенцию, управляемую компонентом, для реализации Ваших собственных методов поиска или для создания пользовательского кэша базы данных.

Типы контейнеров


Процесс размещения устанавливает компоненты J2EE-приложения в J2EE-контейнеры, как показано на рисунке 5.

— J2EE-сервер: является частью времени исполнения J2EE-приложения. J2EE-сервер предоставляет EJB и Web-контейнеры.

— Корпоративный EJB-контейнер: управляет исполнением корпоративных компонентов для J2EE-приложений. Корпоративные компоненты и их контейнер выполняются на J2EE-сервере.

— Web-контейнер: управляет исполнением JSP-страницы и сервлетов для J2EE-приложения. Web-компоненты и их контейнер выполняются на J2EE-сервере.

— Контейнер клиентского приложения: управляет исполнением компонентов клиентского приложения. Клиентские приложения и их контейнер выполняются на клиенте.

— Контейнер апплетов: управляет выполнением апплетов. Состоит из web-броузера и Java- plug-in, выполняющихся на клиенте совместно.

Рисунок 5. J2EE-сервер и контейнеры

Пакетирование

J2EE-компоненты упаковываются раздельно и связываются в J2EE-приложение. Каждый компонент, его файлы, такие как GIF и HTML-файлы, или сервисные классы на сервере и дескриптор размещения компонуются в модуль и добавляются в J2EE-приложение. J2EE-приложение состоит из одного или нескольких модулей корпоративных компонентов, web-компонентов или компонентов клиентского приложения. Окончательное корпоративное решение может использовать одно J2EE-приложение или состоять из двух и более J2EE-приложений в зависимости от требований проекта.

J2EE-приложение и каждый из его модулей имеет собственный дескриптор размещения. Дескриптор размещения является XML-документом с расширением .xml, описывающим установки размещения компонента. Дескриптор размещения модуля корпоративного компонента, например, описывает атрибуты транзакции и уровень безопасности для корпоративного компонента. Т.к. информация дескриптора размещения является описательной, она может меняться без изменения исходного кода компонента. Во время выполнения J2EE-сервер читает дескриптор размещения и соответствующим образом обрабатывает компонент.

J2EE-приложение со всеми своими модулями поставляется в файле корпоративного архива (EAR). EAR-файл является стандартным Java-архивом (JAR) с расширением .ear. В GUI-версии J2EE SDK Вы сначала создаете EAR-файл и добавляете JAR и WAR (Web Archive) файлы в EAR. Если Вы используете средства пакетирования командной строки, Вы сначала создаете JAR и WAR файлы, а затем создаете EAR. J2EE SDK инструменты описаны в разделе «Инструменты».

Каждый EJB JAR-файл содержит дескриптор размещения, файлы корпоративных компонентов и связанные с ними файлы.

Каждый JAR-файл клиентского приложения содержит дескриптор размещения, файлы классов клиентского приложения и связанные с ними файлы.

Каждый WAR-файл содержит дескриптор размещения, файлы Web-компонентов и связанные с ними ресурсы.

Использование модулей и EAR-файлов делает возможной компоновку нескольких различных J2EE-приложений, используя некоторые из тех же самых компонентов. Никакое дополнительное кодирование не требуется; это вопрос компоновки различных J2EE-модулей в EAR-файлы.

Роли в разработке ПО

Модули повторного использования дают возможность разделить процесс разработки и размещения приложения на отдельные составляющие, так что разные люди и компании могут выполнять различные части процесса.

Первые две фазы включают приобретение и инсталляцию J2EE-приложения и инструментов. Когда программное обеспечение приобретено и установлено, J2EE-компоненты могут быть разработаны поставщиками компонентов приложения, скомпонованы сборщиками приложения и размещены установщиками. В большой организации каждая из этих фаз может выполняться различными специалистами или их группами. Такое разделение труда работает, потому что на каждой фазе создается переносимый файл, являющийся входным для следующей фазы. Например, на фазе разработки компонента приложения разработчик корпоративного компонента создает EJB JAR-файлы. На фазе компоновки приложения другой разработчик компонует эти файлы в J2EE-приложение и сохраняет его как EAR-файл. На фазе размещения приложения системный администратор на сайте пользователя использует EAR-файл для инсталляции J2EE-приложения на J2EE-сервере.

Различные фазы не всегда выполняются разными людьми. Если вы работаете в маленькой компании или разрабатываете простое приложение, вы можете выполнять задачи на всех фазах.

Поставщик J2EE-продукта

Поставщиком J2EE-продукта является компания, которая проектирует и продает J2EE-платформу, наборы API и другие средства, определенные в спецификации J2EE. Обычно поставщики продукта – это продавцы операционной системы, системы управления базами данных, сервера приложений или Web-сервера, которые поставляют J2EE-платформу согласно спецификации J2EE.

Поставщик инструмента

Поставщик инструмента – это компания или человек, который создает средства разработки, компоновки и пакетирования, используемые поставщиками компонентов, компоновщиками и установщиками. Для более детальной информации о средствах, доступных в J2EE SDK версии 1.3, смотри раздел «Инструменты».

Поставщик компонента приложения

Поставщиком компонента приложения является компания или человек, который создает Web-компоненты, корпоративные компоненты, апплеты или клиентские приложения для использования в J2EE-приложениях.

Разработчик корпоративного компонента

Разработчик корпоративного компонента выполняет следующие задачи по созданию EJB JAR-файла, содержащего корпоративный компонент:

Создает и компилирует исходный код.

Описывает дескриптор установки.

Собирает class-файлы и дескриптор установки в EJB JAR-файл.

Разработчик Web-компонента

Разработчик Web-компонента выполняет следующие задачи по созданию WAR-файла, содержащего Web-компонент:

Создает и компилирует исходный код сервлета.

Создает JSP и HTML-файлы.

Описывает дескриптор установки для Web-компонента.

Собирает .class, .jsp, .html-файлы и дескриптор установки в WAR-файл.

Разработчик клиентского приложения J2EE

Разработчик клиентского приложения выполняет следующие задачи по созданию JAR-файла, содержащего клиентское приложение J2EE:

Создает и компилирует исходный код.

Описывает дескриптор установки для клиента.

Собирает .class-файлы и дескриптор установки в JAR-файл.

Компоновщик приложения

Компоновщик приложения — это компания или человек, который получает JAR-файлы компонента приложения от поставщика компонента и компонует их в EAR-файл J2EE-приложения. Компоновщик или установщик может редактировать дескриптор установки непосредственно, или используя инструменты, которые корректно добавляют XML-тэги в диалоговом режиме. Разработчик программного обеспечения выполняет следующие задачи по созданию EAR-файла, содержащего J2EE-приложение:

Собирает EJB JAR и WAR-файлы, созданные на предыдущих этапах, в EAR-файл J2EE-приложения.

Описывает дескриптор установки для J2EE-приложения.

Проверяет корректность содержимого EAR-файла и его соответствие спецификации J2EE.

Установщик приложения и администратор

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

В процессе конфигурирования установщик следует инструкциям, предоставленным поставщиком компонента приложения, для разрешения внешних зависимостей, определяет настройки безопасности и назначает атрибуты транзакции. В процессе инсталляции установщик размещает компоненты приложения на сервере и генерирует зависящие от контейнера (container-specific) классы и интерфейсы.

Установщик/системный администратор выполняет следующие задачи по инсталляции и конфигурированию J2EE-приложения:

Добавляет EAR-файл J2EE-приложения, созданный на предыдущем этапе, на J2EE-сервер.

Конфигурирует J2EE-приложение под рабочее окружение, изменяя дескриптор установки J2EE-приложения.

Проверяет корректность содержимого EAR-файла и его соответствие спецификации J2EE.

Инсталлирует EAR-файл J2EE-приложения на J2EE-сервере.

Программное обеспечение

J2EE SDK – некоммерческое практическое определение платформы J2EE и спецификация, свободно распространяемые Sun Microsystems для демонстрации, апробирования и обучения. J2EE SDK включает в себя сервер приложений J2EE, Web-сервер, реляционную базу данных, набор J2EE API и полный набор инструментов для разработки и установки. J2EE SDK можно загрузить с

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

Доступ к базам данных

Реляционная база данных обеспечивает постоянное место хранения данных приложения. Для реализации J2EE не требуется поддержки определенного типа базы данных. Это означает, что базы данных, поддерживаемые различными J2EE-продуктами, могут быть разными. Список баз данных, поддерживаемых в данной реализации, приведен в Release Notes, включенном в J2EE SDK.

J2EE API

Для запуска J2EE SDK необходимо наличие: Java 2 Platform, Standard Edition (J2SE) SDK, которая предоставляет основные API для создания J2EE-компонентов, основные инструменты разработки и виртуальную машину Java. J2EE SDK предоставляет описанные ниже API, используемые в J2EE-приложениях.

Технология Enterprise JavaBeans 2.0

Корпоративный компонент представляет собой код с полями и методами, реализующий модули бизнес-логики. Корпоративный компонент можно представить в виде строительного блока, который может использоваться как самостоятельно, так и совместно с другими компонентами, для исполнения бизнес-логики на J2EE-сервере.

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

Цукерберг рекомендует:  Привлекательная анимированная круглая диаграмма
JDBC API 2.0

JDBC API позволяет вызывать SQL-команды из методов языка программирования Java. JDBC API используется также в корпоративных компонентах при изменении установленной по умолчанию персистенции, управляемой контейнером, или при обращении к базе данных из сессионного компонента. При персистенции, управляемой контейнером, операции доступа к базе данных обрабатываются контейнером, т.е. реализация корпоративного компонента не содержит кода JDBC или SQL-команд. Также, возможно использование JDBC API в сервлете или JSP-странице для прямого доступа к базе данных, минуя корпоративный компонент.

JDBC API состоит из двух частей: интерфейса прикладного уровня, используемого компонентами приложения для доступа к базе данных, и интерфейса поставщика сервиса, используемого для подключения JDBC-драйвера к J2EE-платформе.

Технология Java Servlet 2.3

Технология Java Servlet позволяет определить классы сервлетов. Класс сервлета расширяет возможности серверов, доступные хост-приложениям при использовании ими модели программирования «запрос — ответ». Хотя сервлеты могут отвечать на запросы любого типа, они обычно используются в приложениях, поддерживаемых Web-серверами.

Технология JavaServer Pages 1.2

Технология JavaServer Pages позволяет встраивать фрагменты кода сервлета прямо в текстовые документы. JSP-страница представляет собой текстовый документ, который содержит два типа текста: статичные шаблонные данные, которые могут быть представлены в любом текстовом формате, таком как HTML, WML и XML, а также JSP-элементы, которые определяют способ построения динамичного содержимого страницы.

Java Message Service 1.0

JMS представляет собой стандарт обмена сообщениями, позволяющий компонентам J2EE-приложения создавать, посылать, принимать и читать сообщения. Он обеспечивает двустороннее, надежное, асинхронное распределенное соединение. Дополнительную информацию по JMS можно получить в руководстве по Java Message Service на

Java Naming and Directory Interface 1.2

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


Поскольку JNDI не зависит от какой бы то ни было специализированной реализации, приложения могут использовать JNDI для доступа к многочисленным сервисам имен и каталогов, включая такие сервисы, как LDAP, NDS, DNS и NIS. Это позволяет J2EE-приложениям сосуществовать с традиционными приложениями и системами. Дополнительную информацию по JNDI можно получить в онлайн-руководстве по JNDI на

Java Transaction API 1.0

Java Transaction API (JTA) обеспечивает стандартный интерфейс для разделенных транзакций. J2EE-архитектура обеспечивает автоматическую фиксацию транзакции по умолчанию для управления фиксацией и откатом транзакций. Автофиксация означает, что любые другие приложения, просматривающие данные, будут видеть обновленные данные после каждой операции чтения или записи в базу данных. Однако если приложение выполняет две отдельные операции доступа к базе данных, зависящие друг от друга, необходимо использовать JTA API для разграничения целостной транзакций, включающей обе операции, на начало, откат и фиксацию.

JavaMail API 1.2

Приложение J2EE может использовать JavaMail API для отправления e-mail сообщений. JavaMail API состоит из двух частей: интерфейса прикладного уровня, используемого компонентами приложения для отправления почты, и интерфейса поставщика сервиса. J2EE-платформа включает JavaMail вместе с поставщиком сервиса, что позволяет компонентам приложения отправлять Интернет-почту.

JavaBeans Activation Framework 1.0

JavaBeans Activation Framework (JAF) используется JavaMail. Он предоставляет стандартные сервисы для определения типа произвольных частей данных, инкапсулирует доступ к ним, разрешает операции над ними, и создает соответствующий JavaBeans-компонент для выполнения этих операций.

Java API for XML Processing 1.1

XML – это язык для представления текстовых данных таким образом, чтобы эти данные могли быть прочитаны и обработаны любой программой или инструментом. Программы и инструменты могут генерировать XML-документы, которые могут быть прочитаны и обработаны другими программами и инструментами. Java API for XML Processing (JAXP) поддерживает обработку XML-документов, используя DOM, SAX и XSLT. JAXP позволяет приложениям анализировать и преобразовывать XML-документы независимо от особенностей реализации XML-обработки.

Например, J2EE-приложение может использовать XML для построения отчетов. Различные компании, получив отчеты, могут обрабатывать данные, способом, наиболее соответствующим их требованиям. Одна компания может передать XML-данные в программу, преобразующую XML в HTML для публикации в Web. Другая компания может обработать XML-данные для создания презентации. Третья компания может прочитать XML-данные в свое J2EE-приложение для обработки.

J2EE Connector Architecture 1.0

J2EE Connector Architecture используется поставщиками J2EE-инструментов и системными интеграторами для создания адаптеров ресурсов, поддерживающих доступ к информационной системе предприятия. Эти адаптеры могут быть включены в любой J2EE-продукт. Адаптер ресурса — это программный компонент, позволяющий компонентам J2EE-приложения иметь доступ и взаимодействовать с базовым менеджером ресурсов. Т.к. адаптер ресурса специфичен для своего менеджера ресурсов, обычно существуют различные адаптеры для каждого типа базы данных или информационной системы предприятия.

Java Authentication and Authorization Service 1.0

Java Authentication and Authorization Service (JAAS) предоставляет возможность приложению J2EE аутентифицировать и авторизовывать определенного пользователя или группу пользователей.

JAAS – это Java-версия стандартной системы подключаемого модуля аутентификации PAM (Pluggable Authentication Module), которая расширяет архитектуру безопасности платформы Java 2 поддержкой пользовательской авторизации.

Упрощенная системная интеграция

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

Набор J2EE API обеспечивает системную интеграцию и интеграцию приложений при помощи:

Унифицированой прикладной модели на всех уровнях посредством корпоративных компонентов.

Упрощенного механизма запросов и ответов посредством JSP-страниц и сервлетов.

Надежной модели безопасности посредством JAAS.

Интеграции обмена XML-данными посредством JAXP.

Упрощенного взаимодействия систем посредством архитектуры J2EE-коннектора.

Простого взаимодействия с базой данных посредством JDBC API.

Интеграции корпоративных приложений посредством управляемых сообщениями компонентов и JMS, JTA и JNDI.

Вы можете узнать больше об использовании J2EE-платформы для построения интегрированных бизнес-систем, прочитав «J2EE-технология на практике» на

Инструменты

Реализация J2EE предоставляет средства размещения приложения и набор скриптов для компоновки, проверки и размещения J2EE-приложений, а также управления средой разработки и рабочим окружением. Смотрите приложение В, в котором содержится информация об инструментах.

Инструмент размещения приложения

J2EE-реализация предоставляет инструмент размещения приложения (deploytool) для компоновки, проверки и размещения J2EE-приложений. Существует две версии: командная строка и GUI.

GUI-версия включает мастера для:

Пакетирования, конфигурирования и размещения J2EE-приложений.

Пакетирования и конфигурирования корпоративных компонентов.

Пакетирования и конфигурирования Web-компонентов.

Пакетирования и конфигурирования клиентских приложений.

Пакетирования и конфигурирования адаптеров ресурсов.

Кроме того, информация о конфигурации может быть установлена для каждого типа компонента или модуля на закладке «inspector».

Скрипты

Таблица 1-1 содержит список скриптов, включенных в J2EE-реализацию и позволяющих выполнить действия из командной строки.

Таблица 1. J2EE-скрипты

Запуск и остановка J2EE-сервера

Запуск и остановка базы данных по умолчанию

Добавление JDBC-драйверов, JMS-назначений и мастеров соединений для различных ресурсов

Создание общих и персональных ключей и генерация сертификата X509

Импорт файлов сертификата. Добавление и удаление J2EE пользователей из списка аутентификации и авторизации для J2EE-приложения

Пакетирование компонентов J2EE-приложения в EAR, EJB JAR, JAR и WAR-файлы

Проверка корректности EAR, EJB JAR, JAR и WAR-файлов и соответствия их J2EE-спецификации

Запуск клиентского приложения J2EE

Удаление всех размещенных приложений с J2EE-сервера

H Топ сайтов с серверной частью на Java EE в черновиках

.collapse»>Содержание

Говорят, что Java сильна на серверах. Но сколько я не искал — так и не нашёл адекватного списка популярных сайтов, которые построены на этой технологии. Собственно, в этой статье попытаюсь восполнить пробел. Пользуясь некоторыми сайтами, я даже и не подозревал, что их серверная часть написана на Java EE.

Используя популярный сервис builtwith.com, можно получить представление о серверной части сайта. Как правило, это PHP или ASP, однако J2EE также занимает значительный процент, и, как выяснилось, в весьма серьёзном сегменте.

Аналитика

Для начала выясним, какой же процент занимает Джава. Для этого возьмём две независимые статистики — по использованию фреймворков и по языкам на серверной части:

На основе этих двух диаграмм можно сделать вывод — Java занимает от 2,7 до 7,74 %. Этот процент — в основном высоконагруженные сайты и порталы крупных компаний. Джава берёт не количеством, а качеством. И используется там, где нужда стабильность и надёжность, жёсткие стандарты и спецификации.

Источники

На основе чего нам судить, использует ли сайт Java? Можно попытаться вручную проанализировать ответ сервера. Однако после долгих поисков я наткнулся на замечательный сайт builtwith.com, который по введённому URL определяет серверную часть, и довольно точно. Мы будем использовать его, как основной инструмент. Я рекомендую вам прогнать через этот сервис список ваших любимых сайтов — узнаете много нового.

Совсем недавно я наткнулся на интересную платформу SiTex, которая предназначена для веб-разработки и основана на Java. И именно с этого сайта я взял лого для статьи. Среди заказчиков этой платформы — самые крутые компании и организации нашей страны.

Если работадатели спросят вас, зачем им Джава — скиньте ту ссылочку на компаний-заказчиков. Кто-то не уважает Java и недооценивает всю мощь технологии? Ваш ответ будет прост — Не нравиться Java — скажи это Газпрому. Или МВД.

На основе списка заказчиков SiTex мы можем судить о внутреннем использовании этими компаниями Java, хотя некоторые их сайты написаны не на Java. А в данной статье мы будем формировать список конкретно сайтов.

Список

Я представлю те сайты, с которыми знаком. Однако вполне возможно, что вы знаете много других, не менее популярных сайтов на основе Java. Если так — обязательно напишите об этом в комментариях. Расширим список вместе!

Сразу оговорюсь — я где-то читал, что сайт gmail, yandex, а также сервера для сайтов некоторых крупных компаний, перечисленных в лого, написаны на Java — но сайт builtwith.com не определяет их серверную часть как J2EE. Поэтому не беруюсь без оснований добавлять их в список. Если же вы найдёте доказательства тому — например посты из блогов компаний, где они описывают серверную архитектуру — то обязательно дайте знать — и я их добавлю.

Amazon

Очень популярный интернет магазин. Помимо всего прочего, тут есть описание серверной архитектуры. Довольно часто его приводят как хороший пример использования Java на сервере, и я думаю что большинство читателей уже знало, что он написан на ней.

Юлмарт

А вот это уже было для меня неожиданностью. Я уже много лет заказываю технику через Юлмарт, но я не знал, что он написан на JavaEE!

Популярный интернет аукцион, серверная часть которого также использует Java. Второй классический пример.

Довольно крупная компания. Серверная её часть, как оказывается, также использует Джаву.

Пентагон

Как выяснилось, официальный сайт Пентагона также использует Java. Это ещё раз подчёркивает серьёзность платформы.

Одноклассники

Хотя builtwith.com не определяет тип серверной части для этого сайта, всем известно, что он использует Java. В одной из своих статей компания описала серверную архитектуру.


PayPal

Сайт хорошо известной платёжной системы.

Media Markt

Сайт популярного интернет-магазина

Adobe

Сайт популярной компании-разработчика ПО.

Сайт по линуксу.

Oracle

Oracle использовала Джаву ещё задолго до поглощения Sun Microsystems.

Также, на Java EE построенно два китайских сайта с очень высокой посещаемостью — 163.com и www.taobao.com.

Права на логотипы, предоставленные в статье, принадлежат соответствующим компаниям.

Enterprise JavaBeans

Что такое EJB (Enterprise JavaBeans) и для чего она нужна? Можно ли обойтись без EJB при разработке WEB-приложений? Что даёт EJB программистам?

В java WEB-приложении можно использовать JSP (JavaServer Pages), JavaServer Faces (JSF), Struts, GWT. Для работы с базой данных можно использовать JDBC (Java Database Connectivity) или JPA (JBoss Hibernate). Применение в WEB-приложении servlet’a позволяет перехватить обращение к серверу и выполнить определенные действия, т.е. выполнить фильтрацию сообщений. Где и как в WEB-приложении можно использовать EJB?

Опыт показывает, что типовые задачи имеют типовые решения. Это и обеспечивает EJB, который представляет набор «фиксированных» решений типовых проблем, возникающих при разработке серверных приложений, а также проверенная временем схема реализации серверных компонентов. Эти фиксированные решения, или службы, предоставляются «контейнером EJB». Для доступа к этим службам необходимо создать специализированные компоненты, используя декларативные и программные EJB API, и развернуть их на сервере приложений.

Сервер приложений Java EE (Enterprise Edition) включает два основных компонента : WEB-container (для использования JSP, JSF, Struts и т.д.) и EJB-container. Первый компонент используется для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики WEB-приложения. Для этого используется EJB-container.

Enterprise JavaBeans имеет спецификацию написания и поддержки серверных компонентов, содержащих бизнес-логику. Данная технология применяется, как правило, в том случае, если бизнес-логика требует один или несколько следующих сервисов :

  • сервис распределённых транзакций;
  • сервис сохранности данных (persistence);
  • сервис управления данными;
  • сервис событий;
  • сервис именования и каталогов (JNDI);
  • сервис безопасности и ограничения доступа к данным.

Технологию EJB можно рассматривать в двух аспектах: фреймворк и компонент. С точки зрения фреймворка EJB — это технология, предоставляющая для серверной части WEB-приложения множество готовых решений (управление транзакциями, безопасность, хранение информации и т.п.). С точки зрения компонента EJB — это надстройка над POJO-классом, описываемая с помощью аннотаций.

Основные типы компонентов EJB

В языке EJB под компонентом подразумевается зерно (Bean), а под Enterprise подразумевают «корпоративный». EJB делит компоненты (зерна) на несколько типов, исходя из их предназначения :

  • сессионные (Session Beans), которые могут быть
    • stateful — с сохранением текущего состояния;
    • stateless — без сохранения состояния;
    • singleton — один объект для всех приложений (начиная с EJB версии 3.1).
  • управляемые сообщениями (Message Driven Beans) — их логика является реакцией на события в системе;
  • объектные (Entity Bean) — определены в спецификации JPA (Java Persistence API) entities и используются для хранения данных.

Сессионный компонент Session Beans, иначе называемый сеансовый, вызывается клиентом (браузером) для выполнения вполне определенных операций, таких как, к примеру, проверка кредитной истории клиента. Слово «сессионный» предполагает, что экземпляр компонента доступен только на время выполнения определенной задачи сервером, и безвозвратно уничтожается в случае аварии или остановки сервера. Для доступа к серверной части приложения, клиент вызывает методы сессионного компонента, выполняющего определенные бизнес-задачи внутри сервера.

Сеансовый компонент с сохранением состояния EJB stateful автоматически сохраняет свое состояние между обращениями к нему от одного и того же клиента, и завершает свое существование либо по таймауту, либо по явному запросу клиента. Типичным примером компонента с сохранением состояния является корзина с покупками в интернет-магазине.

Сеансовые компоненты без сохранения состояния EJB stateless не хранят никакой информации о своем состоянии и являются прикладными службами, которые выполняют все необходимые действия в рамках запроса. EJB stateless можно использовать для реализации таких операций, как перевод средств на кредитную карту или проверку кредитной истории клиента. На основе stateless-бинов проектируются WEB-сервисы.

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

Сеансовые компоненты могут вызываться локально или удаленно, посредством Java RMI. Компоненты-одиночки и компоненты без сохранения состояния могут также экспортироваться в виде веб-служб SOAP (Simple Object Access Protocol) или REST (Representational State Transfer).

Компоненты управляемые сообщениями MDB (Message-Driven Bean) подобно сеансовым компонентам реализуют некоторую прикладную логику и имеют одно важное отличие: клиенты никогда не вызывают методы MDB напрямую. Вместо этого компоненты MDB вызываются для обработки отправленных на сервер сообщений, что позволяет организовать асинхронный обмен сообщениями между частями системы. Типичными примерами подобных серверов сообщений могут служить IBM WebSphere MQ, Oracle Advanced Queueing и TIBCO. Компоненты MDB, как правило, применяются для повышения надежности интеграции систем и асинхронной обработки данных. Примером MDB сообщения может быть запрос на доставку товарных запасов от автоматизированной системы розничной торговли к системе управления поставками.

Entity Bean и Java Persistence API

EJB тесно связан с двумя спецификациями : с JPA, которая является стандартом хранения данных для Java EE и с CDI (Contexts and Dependency Injection) которая обеспечивает возможность внедрения зависимостей и предоставляет службы управления контекстом для всех компонентов Java EE, включая EJB.

Возможность автоматического сохранения объектов в реляционной БД с использованием технологии объектно-реляционного маппинга (ORM) — так называемый механизм работы с persistence объектами, является одним из главных достоинств EJB. В контексте EJB persistence провайдер — это ORM-фреймворк, который поддерживает JPA, определяющий стандарт для :

  • конфигурации маппинга Entity Bean и его отображения в БД;
  • EntityManager API — стандартный API для CRUD (Create, Read, Update, Delete) операций над сущностями;
  • Java Persistence Query Language (JPQL) — для поиска и получения данных приложения.

EntityManager API — это интерфейс, который связывает класс сущности приложения (Entity Bean) и её представления в БД. EntityManager знает как нужно добавлять сущности в БД, обновлять и удалять их, а также предоставляет механизмы для настройки производительности, кэширования, транзакций и т.д. Для этого используется язык запросов JPQL, очень похожий на SQL.

Контейнеры EJB-container

Java-приложениям для работы нужна виртуальная машина JVM (Java Virtual Machine). Сеансовым компонентам и компонентам MDB для работы точно также необходим контейнер EJB. Можно считать EJB-container развитием базовой идеи JVM. Так же, как JVM прозрачно управляет памятью, EJB-container обеспечивает компоненты EJB такими службами, как обработка транзакций, поддержка безопасности, удаленные взаимодействия и веб-службы.

Согласно спецификации EJB3 контейнер предоставляет службы, применимые только к сеансовым компонентам и MDB. Операция добавления компонента EJB3 в контейнер называется развертыванием (deployment). После того, как EJB-компонент благополучно развернут в контейнере, он готов к использованию приложениями.

В Java технологиях контейнеры не ограничены только EJB3. Контейнер Java EE – это сервер приложений с поддержкой EJB3, веб-контейнеров (сервлеты, JSP, JSF, Struts, GWT) и других Java EE API и служб. Примерами реализаций контейнеров Java EE могут служить следующие серверы приложений : Oracle WebLogic, GlassFish, IBM WebSphere, JBoss и Caucho Resin.

Определение наименования компонентов EJB

Формат именования компонентов EJB имеет следующий вид :

  • workspace — пространство имен;
  • app-name — наименование приложения;
  • module-name — наименование модуля;
  • ejb-name — наименование компонента;
  • object-name — полное наименование объекта.

В представленном формате именования компонентов EJB ряд элементов (workspace, module-name, ejb-name) присутствуют в имени всегда и являются обязательными. А элементы [app-name] и [!object-name] могут отсутствовать и считаются необязательными.

workspace

Сервер Java EE может включать четыре пространства имен workspace, каждое из которых представляет свою область видимости.

Скрипт Описание
java:comp Область видимости компонента. Все компоненты EJB из WAR-файла попадают в одно общее пространство имен java:comp. Скорее всего Вам редко придется пользоваться этим пространством имен, поскольку основное его предназначение – сохранение обратной совместимости с версиями Java EE 6 и ниже, где java:comp было единственным стандартным пространством имен.
java:module Область видимости модуля. Все компоненты модуля попадут в одно пространство имен java:module. Для обратной совместимости java:comp и java:module интерпретируются в веб-модулях как одно пространство имен. Когда это возможно, вместо java:comp следует использовать java:module.
java:app Область видимости приложения. Компоненты из всех модулей одного приложения размещаются в общем пространстве имен java:app. Примером приложения может служить архив EAR. Все WAR- и EJB-компоненты, развертываемые из EAR-архива попадают в это пространство имен.
java:global Глобальное пространство имен. В java:global размещаются все компоненты из всех модулей и всех приложений.

app-name

Значение наименования приложения [app-name] не является обязательным и присутствует только в именах тех компонентов EJB, которые развертываются на сервере приложений из EAR-архива. Если архив EAR не использовался, тогда [app-name] отсутствует в переносимых именах JNDI компонентов EJB. По умолчанию в качестве значения [app-name] выбирается имя EAR-файла без расширения .ear. Переопределить это умолчание можно в файле application.xml.

module-name

Значение module-name всегда присутствует в наименовании ресурса и является обязательным. Оно зависит от того, как развертываются модули, содержащие компоненты EJB. Если компоненты развертываются из отдельных файлов EJB-JAR (JAR-файлы развертываются непосредственно), в качестве значения module-name выбирается имя EJB-JAR файла без расширения .jar. Это умолчание можно переопределить с помощью элемента module-name в конфигурационном файле META-INF/ejb-jar.xml.

Если развертываются компоненты, являющиеся частью веб-модуля (WAR-файл), по умолчанию в качестве значения module-name выбирается имя WAR-файла без расширения .war. Это умолчание можно переопределить с помощью элемента module-name в конфигурационном файле WEB-INF/web.xml. Если развертываются компоненты, являющиеся частью приложения (EAR-файл), по умолчанию значение module-name определяется в зависимости от того, являются ли компоненты EJB частью EJB-JAR или WAR в EAR. При развертывании компонентов из WAR-файла, выбор значения module-name выполняется в соответствии с правилом для WEB-модулей, которое можно переопределить в дескрипторе WEB-INF/web.xml. При развертывании компонентов из файлов EJB-JAR, значением module-name становится полный путь к каталогу, где находится файл EJB-JAR внутри EAR, плюс имя файла EJB-JAR без расширения .jar, которое можно переопределить в файле META-INF/ejb-jar.xml.

ejb-name

Значение наименования компонента ejb-name является обязательным и всегда присутствует в наименовании ресурса. Для компонентов EJB, помеченных аннотациями @Stateless, @Stateful или @Singleton, в качестве значения ejb-name по умолчанию выбирается имя класса компонента. Это значение можно переопределить с помощью атрибута name() аннотации. Для компонентов EJB, объявленных в файле ejb-jar.xml, значение ejb-name определяется с помощью элемента bean-name.

object-name

Значение полного наименования объекта [!object-name] является обязательным, и переносимые имена компонентов EJB с этим элементом всегда будут присутствовать в JNDI. Но сервер EE также требует, чтобы в JNDI присутствовало имя без этого значения. Такое «усеченное» наименование может пригодиться, когда доступ к компоненту осуществляется через единственный интерфейс (или если компонент вообще не имеет интерфейса).

Что такое Java EE?

Я понимаю, что буквально это переводится на Java Enterprise Edition. Но то, что я спрашиваю, что это действительно означает? Когда компания требует Java EE опыт, то, что они действительно просят? Опыт работы с EJBs? Опыт работы с веб-приложений на Java?

Я подозреваю, что это означает что-то другое для разных людей и определение носит субъективный характер.

Java EE представляет собой набор спецификаций для разработки и развертывания корпоративных приложений.

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

Спецификации (определяемые Sun) описывают услуги, интерфейсы прикладного программирования (API) и протоколы.

В 13 основных технологий, которые составляют Java EE являются:

Поставщик продукта Java EE обычно является поставщик сервера приложений, веб-сервер, или базы данных системы, который обеспечивает классы, которые реализуют интерфейсы, определенные в спецификации. Эти производители конкурируют на реализации спецификаций Java EE.

Когда компания требует Java EE опыт, что они действительно просят за это опыт использования технологий, которые составляют Java EE. Зачастую, компания будет использовать только подмножество технологий Java EE.

Java EE фактически представляют собой совокупность технологий и интерфейсов API для платформы Java, предназначенной для поддержки «Enterprise» Приложения, которые обычно могут быть классифицированы как крупномасштабные, распределенным, транзакционные и высоко доступными приложения, предназначенные для поддержки критически важной бизнес-требований.

С точки зрения того, что сотрудник ищет в конкретных санитаров, довольно трудно сказать, потому что игровое поле менялось в течение последних пяти лет. Это на самом деле о классе задач , которые решаются более чем что — либо еще. Операции и распределение являются ключевыми.

J (2) Е.Е., строго говоря, представляет собой набор API S (как текущий ответ сверху имеет его) , которые позволяют программисту создавать распределенные системы, транзакционные. Идея состояла в том , чтобы абстрагироваться от сложных распределенных, транзакционных битов (которые будут реализованы с помощью контейнера , таких как WebSphere или Weblogic), оставляя программисту для разработки бизнес — логики , свободный от забот о механизмах хранения и синхронизации.

На самом деле, это была мощеной-вместе, дизайн по-комитета миш-маш, который был выдвинут в значительной степени в интересах производителей, как IBM, Oracle и BEA, чтобы они могли продавать ridicously чрезмерно сложным, избыточны, сверх- бесполезные продукты. Который не имеет самые основные функции (такие как планирование)!

J2EE был маркетинг конструкт.

Есть 2 версии Java Среды, J2EE и Se. SE является стандартной версии, которая включает в себя все основные классы, которые вам нужно будет писать приложения на одного пользователя. В то время как Enterprise Edition создан для многоуровневых корпоративных приложений, или возможных распределенных приложений. Если бы с помощью серверов приложений, как кот или WebSphere, вы хотите использовать J2EE, с дополнительными классами для поддержки многоуровневой.

Это означает указания на все время. Он используется для обозначения сервлетов и JSP и EJBs. Теперь-а-дней это, вероятно, означает, что весной и спящий режим и т.д.

На самом деле то, что они ищут это опыт и понимание экосистемы Java, Servlet контейнеров, JMS, JMX, спящий режим и т.д., и, как все они подходят друг к другу.

Тестирование и контроль источника будет одним из важных навыков тоже.

Да, опыт работы с EJB, Web Apps (servlest и JSP), транзакции, веб-сервисы, серверы управления и приложений.

Это также означает, что опыт работы с «Enteprise» приложением уровня, в отличие от настольных приложений.

Во многих ситуациях корпоративные приложения необходимо подключиться к с рядом унаследованных систем, они не только «веб-страниц», и с особенностями availalble на «издание» Явы такого рода соединения могут быть решены.

Я хотел бы сказать, что опыт опыта J2EE = углубленный с несколькими J2EE технологий, общие знания о большинстве J2EE технологий, и общий опыт работы с программным обеспечением предприятия в целом.

J2EE традиционно называют продукты и стандарты, выпущенных Sun. Например, если вы разрабатывали стандарт J2EE веб-приложение, вы будете использовать EJBs, Java Server Faces, и работает на сервере приложений, который поддерживает стандарт J2EE. Однако, так как есть такой огромное открытый источник множество библиотек и продуктов, которые делают ту же работу, а также (и многие поспорят лучше), то эти предложения Sun, день в день смысл J2EE мигрировали в виде эти, а также ( например родник решения / Tomcat / Hibernate) во многих умах.

Это большая книга , на мой взгляд , что обсуждает подход « с открытым исходным кодом» для J2EE http://www.theservers >

Похоже, Oracle сейчас пытается избавиться от JSPs (замените Faces) и эмулировать Spring отдохнет (JAX-RS) и DI.

Таблица 2-1 Web-уровня Java EE Technologies

JavaServer Faces технологии

Рамочный компонент пользовательского интерфейса для веб-приложений, который позволяет включать компоненты пользовательского интерфейса (например, поля и кнопки) на странице XHTML, называется страницу Facelets; преобразования и проверки данных компонентов пользовательского интерфейса; сохранить данные компонентов пользовательского интерфейса для хранилищ данных на стороне сервера; и поддерживать состояние компоненты

Язык выражений

Набор стандартных тегов, используемых на страницах Facelets для обозначения компонентов EE Java

сервлеты

Java классов языка программирования, который динамически обрабатывать запросы и конструируют ответы, как правило, для HTML-страниц

Контексты и Dependency Injection для Java EE

Набор контекстных услуг, которые делают его легким для разработчиков использовать корпоративные компоненты вместе с JavaServer Faces технологии в веб-приложениях

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих