Введение

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

Платформа Java™ 2 Platform, Enterprise Edition (J2EE™) специально предназначена для указанной цели. Она предоставляет хорошо документированную стандартизованную среду для разработки и запуска распределенных, многоуровневых, основанных на компонентах приложений на Java. Эта среда автоматически выполняет большую часть низкоуровневой работы при создании приложения, например, настройку служб удаленных соединений, присвоения имен, постоянных данных, защиты и управления транзакциями, позволяя разработчикам сосредоточиться на бизнес-логике приложения.

Состав платформы J2EE:

• Набор стандартов для компонентов J2EE и для платформы J2EE, на которой работают эти компоненты.
• Эскиз проекта разработки приложения, подробно описывающий платформу J2EE и содержащий ценную информацию о том, как следует разрабатывать приложения J2EE.
• Справочная реализация платформы J2EE, предоставленная фирмой Sun Microsystems Inc. в качестве стандарта, с которым можно сравнивать создаваемые коммерческие продукты J2EE. Справочная реализация содержит полностью готовые к использованию примеры приложений.
• Набор тестов на совместимость, предназначенный для проверки и оценивания коммерческих реализаций J2EE относительно стандартов J2EE.

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

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

Дополнительная информация приведена в обзоре платформы J2EE фирмы Sun на Web-сайте http://java.sun.com/. Выберите ссылку Products & APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) > Overview.

Разработка J2EE в Nutshell

С точки зрения разработчика приложения:

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

Пример

Простой пример приложения J2EE - сайт электронной коммерции, когда клиент (пользователь) удаленно обращается к серверу J2EE с помощью Web-браузера. Сервер J2EE предоставляет службы Web-уровня и бизнес-уровня и взаимодействует с уровнем Enterprise Information Systems (базовым), обеспечивающим доступ RDBMS.

Зачем нужна платформа J2EE?

Платформу J2EE удобно использовать для разработки приложения электронной коммерции на языке Java или приложения предприятия в следующих случаях:

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

Каждый из этих пунктов подробнее рассматривается ниже в этом разделе.

Стандартизованная, апробированная в промышленности среда

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

• J2SE 1.4
  • JDBC
  • Java IDL
  • Remote Method Invocation с Internet Inter-ORB Protocol (RMI-IIOP) CORBA
  • Java Naming and Directory Interface (JNDI)
  • Служба идентификации и проверки прав доступа Java (JAAS)
• API транзакций Java (JTA)
• JavaMail
• Служба сообщений Java (JMS).
  Дополнительная информация о JMS приведена в разделе Концепция: служба сообщений Java (JMS).
• Среда активации объектов JavaBean (JAF)
• Объекты EJB
• Сервлет Java
• API Java для обработки XML (JAXP)
• Коннектор Java (Примечание: не поддерживается в версиях ранее J2EE 1.3)
• Страницы JSP
• Web-службы для J2EE (Примечание: не поддерживаются в версиях ранее J2EE 1.4)
• API Java для RPC на основе XML (JAX-RPC) (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• SOAP с вложениями API для Java (SAAJ) (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• API Java для реестров XML (JAXR) (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• Управление J2EE (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• Расширения управления Java (JMX) (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• Развертывание J2EE (Примечание: не поддерживается в версиях ранее J2EE 1.4)
• Java Authorization Service Provider Contract for Containers (JACC) (Примечание: не поддерживается в версиях ранее J2EE 1.4)

Переносимость

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

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

Многоразовые компоненты

Поскольку компоненты J2EE соответствуют стандарту J2EE, их можно приобретать уже в готовом виде и вставлять в приложение J2EE, экономя на разработке (особенно на отладке и тестировании).

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

Проверенная архитектура и шаблоны проектов

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

Состав документации по J2EE:

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

Дополнительная информация о платформе J2EE приведена на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints.

Масштабируемость

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

• Функции повышения производительности в контейнере J2EE - к таким функциям относятся пулы ресурсов (пулы соединений с базами данных, пулы экземпляров сеансовых объектов EJB и пулы нитей), асинхронная передача сообщений и эффективное управление жизненным циклом компонентов. Например, соединение с базой данных открывается медленно. Кроме того, соединение с базой данных может быть достаточно труднодоступным ресурсом из-за, к примеру, лицензионных ограничений. Платформа J2EE решает эту проблему с помощью пула соединений с базами данных: контейнер J2EE содержит пул открытых соединений, которые можно выделять компоненту по мере необходимости, что делает работу с соединениями быстрой и эффективной.
• Распределение нагрузки может достигаться за счет кластеризации - развертывание одних и тех же компонентов на нескольких серверах, находящихся на разных компьютерах. Нагрузку, выпадающую на серверы, впоследствии можно выравнивать с помощью, например, карусельного алгоритма или в зависимости от нагрузки на каждый сервер. Согласно спецификации платформы J2EE, наличие функции распределения нагрузки на сервере J2EE необязательно, но рекомендуется. Вендоры сервера J2EE предлагают различные средства и способы распределения нагрузки.
• Логическое разделение приложения - логически различные части приложения можно развернуть на разных серверах; например, реестр приложения электронного заказа по почте можно развернуть на одном сервере, а его учетные подсистемы - на другом.

Инструменты разработки и развертывания

В ответ на потребность в инструментах J2EE вендоры предложили великолепную поддержку средств разработки J2EE в своих средах Integrated Development Environment (IDE) Java. Ниже перечислены компоненты этой поддержки:

• Мастеры создания сервлетов
• Мастеры и окна создания и обслуживания объектов EJB
• Средства создания и обслуживания файлов описания
• Средства отображения объектов EJB в базы данных (включая создание информации файла описания для взаимосвязей, управляемых контейнером)
• Интеграция с Web-контейнером для тестирования Web-служб
• Прозрачные развертывание, отладка и тестирование объектов EJB внутри IDE путем их интеграции с контейнером EJB J2EE и его инструментами развертывания
• Автоматическое создание пробных клиентов J2EE
• Интеграция с инструментами моделирования UML

Интеграция на базовом уровне

Под базовым уровнем в данном случае понимается уровень информационной системы предприятия (Enterprise Information System, EIS) приложения. Базовыми системами могут быть, например, RDBMS, устаревшие системы или системы планирования ресурсов предприятия (Enterprise Resource Planning, ERP).

J2EE поддерживает доступ через транзакции к EIS RDBMS с помощью API JDBC и JTA. Кроме того, контейнеры EJB поддерживают хранение постоянных данных, управляемое контейнером, когда транзакционное соединение RDBMS и доступ через него обрабатываются контейнером автоматически.

Service Provider Interface (SPI) архитектуры коннектора J2EE определяет стандарт для подключения ресурсов EIS, не относящихся к RDBMS, к контейнеру J2EE. Адаптер ресурсов EIS (поставляемый вендором EIS) встраивается в контейнер J2EE, благодаря чему контейнер может предоставлять EIS защищенную поддержку транзакций. После этого компоненты в контейнере могут получать доступ к EIS через SPI архитектуры коннектора J2EE.

Примечание: SPI архитектуры коннектора J2EE не поддерживается в версиях до J2EE 1.3.

Защита

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

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

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

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

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

Рисунок 1: многоуровневая архитектура J2EE

Клиентский уровень

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

• Автономные приложения Java - обычно это GUI (называемый также "толстым клиентом"). Такое приложение Java должно быть установлено на каждом клиентском компьютере. Приложение Java может обращаться к уровню EIS или среднему уровню посредством API, таких как JDBC.
• Статические страницы HTML - предоставляют ограниченный GUI для приложения.
• Динамический HTML - создается страницами JSP или сервлетами.
• Аплеты - запускаются в Web-браузере. Аплеты встраиваются в страницу HTML и обычно используются как средство предоставления GUI.

Средний уровень

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

Web-уровень

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

Бизнес-уровень

Компоненты бизнес-уровня - это объекты EJB.

• Они содержат бизнес-логику приложения.
• Они отправляют запросы на EIS-уровень в соответствии с бизнес-логикой, обычно в ответ на запрос из Web-уровня.

EIS-уровень

EIS-уровень представляет хранимые данные приложения, часто в форме RDBMS. EIS-уровень может также состоять из устаревших систем или ERP, доступ к которым осуществляется через API архитектуры коннектора J2EE.

Дополнительная информация о API архитектуры коннектора J2EE приведена на Web-сайте http://java.sun.com/. Выберите ссылку Products & Technologies > J2EE > J2EE Connector Architecture.

Дополнительная информация о стандартных конфигурациях развертывания J2EE приведена в разделе Концепция: конфигурации развертывания J2EE.

Серверы J2EE

Серверы J2EE - это коммерческие продукты, реализующие платформу J2EE. Примерами коммерческих серверов J2EE могут служить BEA WebLogic, Borland Enterprise Server, IBM WebSphere и iPlanet.

Термин "сервер J2EE" несколько расплывчат. Обычно имеется в виду "сервер J2EE, поддерживающий и контейнер Web, и контейнер EJB". Если использовать более точную терминологию, Web-сервер J2EE (такой как справочный Web-сервер J2EE, реализация Tomcat) поддерживает Web-контейнер; сервер приложения J2EE (или EJB) поддерживает контейнер EJB.

Контейнеры J2EE

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

J2EE определяет следующие типы контейнеров:

• контейнер приложений-клиентов
• контейнер аплетов
• контейнер Web
• контейнер EJB

Контейнер приложений-клиентов

Приложение-клиент J2EE работает в контейнере приложений-клиентов, поддерживающем следующие API J2EE: JDBC, JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, Управление J2EE и JMX.

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

Контейнер аплетов

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

Контейнер Web

Компоненты Web (страницы JSP и сервлеты) работают в контейнере Web, предоставляемом как часть сервера J2EE или автономный Web-сервер J2EE. Контейнер Web поддерживает следующие API и пакеты J2EE: JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, JavaMail, JAF, Архитектура коннектора J2EE, JTA, JSR, SAAJ, Управление J2EE, Сервлет Java и JSP.

Контейнер EJB

Компоненты EJB работают в контейнере EJB, предоставляемом как часть сервера J2EE.

Контейнер EJB поддерживает следующие API и технологии J2EE: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, JavaMail, JAF, JTA, JSR, SAAJ, Управление J2EE и Архитектура коннектора J2EE.

В следующих подразделах перечислены основные функции контейнеров EJB:

• Удаленные соединения
• Параллельность
• Присвоение имен
• Постоянные данные
• Управление транзакциями
• Управление защитой
• Управление жизненным циклом
• Пулы соединений с базами данных
• Сообщения

Удаленные соединения

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

Параллельность

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

Присвоение имен

Контейнер EJB предоставляет пространство имен JNDI для поиска объектов EJB, развернутых в контейнере. Клиенты EJB могут искать объекты EJB, чтобы получить домашний интерфейс. Домашний интерфейс для EJB предоставляет методы поиска и создания экземпляров EJB. Пока контекст имен JNDI доступен из их расположения, клиенты могут обращаться к объектам EJB.

Постоянные данные

Разработчики EJB могут выбрать одну из двух схем хранения постоянных данных сущностных объектов EJB: постоянное хранение, управляемое контейнером (CMP), или постоянное хранение, управляемое EJB (BMP). CMP передает ответственность за реализацию кода доступа к данным контейнеру, в то время как BMP оставляет эту ответственность на разработчике EJB. CMP позволяет разработчику EJB воспользоваться стандартной реализацией для доступа к постоянной памяти, просто объявив поля, управляемые контейнером, в файле описания.

Управление транзакциями

Транзакция - это последовательность операций, которая может быть выполнена только целиком. Это означает, что если какая-либо операция в последовательности не будет выполнена, то состояние системы не изменится. Например, рассмотрим процедуру продажи авиабилетов. Продавец должен убедиться в наличии средств на кредитной карточке покупателя, снять требуемую сумму с нее и затем выдать билет. Эта последовательность операций должна быть выполнена как единое целое: если какая-либо из операций окажется невыполнимой, то кредитная карточка покупателя должна остаться в прежнем состоянии и билеты не должны быть выданы.

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

Демаркация транзакций, управляемая JavaBean

В демаркации транзакций, управляемой JavaBean, демаркация границ транзакций выполняется с помощью простого API. Это API транзакций Java (JTA), применяемый для программного управления демаркацией транзакций; например, путем вызова методов begin(), commit() и rollback() интерфейса UserTransaction JTA. Разработчик отвечает за кодирование логики обратного вызова для условий исключительных ситуаций транзакций, поскольку контейнер не обрабатывает это автоматически.

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

Демаркация транзакций, управляемая контейнером

В демаркации транзакций, управляемой контейнером, вы не предоставляете код для начальной и конечной транзакций. Вместо него вы указываете атрибут транзакции в файле описания EJB для каждого метода EJB. Атрибут транзакции (Required, RequiresNew, NotSupported, Supports, Mandatory или Never) сообщает контейнеру, какую область действия транзакции следует использовать для метода. Например, если клиент работает в транзакции и вызывает метод вашего объекта EJB, для которого атрибут транзакции равен Required, то метод будет вызван в области действия существующей транзакции.

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

Распределенные транзакции

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

В распределенных транзакциях необходима двухфазовая фиксация; например, когда обновляется несколько баз данных. Некоторые контейнеры EJB (такие как BEA WebLogic Server 6.0) предоставляют поддержку двухфазовой фиксации по протоколу XA Open Group. Прикладному программисту не требуется писать код для обработки двухфазовой фиксации; ей управляет контейнер EJB.

Управление защитой

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

Во время выполнения каждому клиенту EJB присваивается некоторая роль. Контейнер EJB управляет доступом к методам EJB, проверяя, разрешено ли данной роли клиента вызывать этот метод.

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

Управление жизненным циклом

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

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

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

• ejbCreate() - вызывается контейнером после создания экземпляра EJB
• ejbRemove() - вызывается контейнером перед удалением экземпляра EJB
• ejbActivate() - вызывается контейнером после восстановления экземпляра EJB из пассивного состояния
• ejbPassivate() - вызывается контейнером перед переключением экземпляра EJB в пассивное состояние
• ejbStore() - вызывается контейнером перед записью экземпляра EJB в базу данных
• ejbLoad() - вызывается контейнером после загрузки полей экземпляра EJB из базы данных

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

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

Пулы соединений с базами данных

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

Для сущностных объектов EJB, использующих CMP, соединения с базами данных обрабатываются автоматически. Создавать соединение или код SQL не нужно - достаточно просто указать имя JNDI источника данных JDBC в файле описания EJB и создать процедуры подключения с помощью инструментов развертывания, предусмотренных в контейнере. Пулом соединений с базами данных управляет контейнер.

Для сущностных объектов EJB, использующих BMP, и для сеансовых объектов EJB необходимо написать код соединения для подключения к источнику данных JDBC и код SQL для доступа к базе данных. Источником данных JDBC, как и в предыдущем случае, управляет контейнер - фактически источник данных JDBC использует управляемый контейнером пул соединений с базами данных.

Сообщения

Для поддержки асинхронного обмена сообщениями необходимы контейнеры EJB. JMS или другие типы служб сообщений могут использоваться объектами EJB, управляемыми сообщениями, для обработки доставляемых сообщений. Взаимодействие JMS с объектами EJB требует, чтобы те поддерживали транзакционный доступ из компонентов контейнеров Web и EJB, таких как сервлеты, страницы JSP и объекты EJB.

Компоненты J2EE

В следующем разделе кратко рассматриваются все типы компонентов J2EE. К компонентам J2EE относятся аплеты, приложения-клиенты, компоненты Web и объекты Enterprise JavaBean. Компоненты J2EE работают в контейнерах J2EE.

Аплеты

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

Аплеты применяются в основном для реализации пользовательских интерфейсов и позволяют значительно расширить возможности страниц HTML.

Приложения-клиенты

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

Компоненты Web

Сервлеты Java

Технология Сервлет Java позволяет Web-серверу обрабатывать запросы, поступающие от Web-клиента, и отправлять ответы с динамическим содержимым. Для создания этого динамического содержимого сервлет Java может взаимодействовать с другими компонентами Web и EJB. Созданное содержимое может принимать форму любого текстового документа, в том числе HTML и XML. Кроме того, технологию Сервлет Java можно применять в качестве конечной точки Web-служб во взаимодействии с API JAX-RPC.

Примечание: применение технологии Сервлет Java в качестве конечной точки Web-служб - это новая функция J2EE 1.4 (JAX-RPC 1.1), не поддерживаемая в предыдущих версиях.

Дополнительная информация о сервлетах J2EE приведена на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints.

Страницы JSP

Технология Страницы JSP основана на сервлетах Java, но вместо кода в ней применяется текст. Страница JSP обрабатывает запросы и выдает ответы, как сервлет, но ее логика контролируется прежде всего презентациями. Страница JSP содержит в основном статический HTML, определяющий формат представления данных, получаемых из других источников, таких как объекты JavaBean и EJB. Для того чтобы добавить новые возможности в JSP, разработчик компонентов Web может создавать библиотеки пользовательских тегов.

Дополнительная информация о JSP приведена на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints.

Страницы HTML

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

Объекты JavaBean

API JavaBean определяет архитектуру для создания простых многоразовых компонентов. Эти компоненты можно редактировать и собирать с помощью инструментов компоновки приложения. Объекты JavaBean реализуются с помощью обычного кода Java, поэтому реализация доступна другим программистам, которым могут понадобиться эти компоненты, а также инструментам.

JavaBean не является технологией J2EE, но используется технологиями J2EE. Например, объекты EJB могут применять объекты JavaBean в качестве значений. Различия между объектами JavaBean и объектами Enterprise JavaBean описаны в разделе Сравнительное описание объектов JavaBean и EJB.

Дополнительная информация об объектах JavaBean приведена в разделе Концепция: объекты JavaBean.

Объекты Enterprise JavaBean

Спецификация объектов Enterprise JavaBean требует архитектуру для разработки и развертывания распределенных бизнес-приложений, основанных на компонентах и поддерживающих транзакции.

Компоненты, определяемые спецификацией EJB, называются объектами Enterprise JavaBean (EJB). Объекты EJB - это серверные компоненты Java, в которых вы реализуете бизнес-правила приложения.

Объекты EJB развертываются и выполняются в среде, называемой контейнером EJB; он был описан ранее в параграфе Контейнер EJB. Этот контейнер предоставляет службы управления транзакциями, соединений с базами данных и защиты. Архитектура EJB скрывает эти подробности, что позволяет разработчикам компонентов сосредоточиться на бизнес-логике.

Объект Enterprise JavaBean (EJB) - это совокупность, состоящая из интерфейсов Java, класса реализации EJB и файла описания XML. Интерфейсы EJB и класс реализации должны отвечать правилам, задаваемым спецификацией EJB, например, они должны реализовывать определенные интерфейсы и предоставлять определенные методы обратного вызова.

Интерфейсы EJB содержат домашние интерфейсы, предоставляющие методы поиска и создания интерфейсов EJB, и интерфейсы компонентов, предоставляющие бизнес-методы для конкретного экземпляра EJB. Это могут быть удаленные интерфейсы, т.е. те, которые можно вызывать по сети, или локальные интерфейсы, которые должны вызываться из того же процесса (точнее, из той же виртуальной машины Java). Интерфейсы EJB реализуются классами контейнера EJB, делегирующими методы классу реализации EJB. Исключение составляет метод поиска в сущностном объекте EJB, управляемом контейнером: он обрабатывается классом контейнера.

Существует три типа объектов EJB: сеансовые объекты, сущностные объекты и управляемые сообщениями объекты.

Дополнительная информация об объектах EJB приведена на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints.

Сеансовые объекты EJB

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

У сеансового объекта EJB может быть метод getAllCustomers(), возвращающий совокупность всех заказчиков, хранящихся в базе данных. Этот сеансовый объект EJB получает информацию из сущностного объекта Customer и доставляет результаты клиенту.

Сеансовые объекты EJB без сохранения состояния могут использоваться в качестве конечной точки Web-служб, согласно спецификации JSR и EJB.

Примечание: применение сеансовых объектов EJB без сохранения состояния в качестве Web-служб - это новая функция J2EE 1.4 (JSR 109 и EJB 2.1), не поддерживаемая в предыдущих версиях.

Дополнительная информация о сеансовых объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.1 на Web-сайте http://java.sun.com/. Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans.

Сущностные объекты EJB

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

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

Существует два типа постоянного хранения сущностных объектов EJB: постоянное хранение, управляемое EJB (BMP), и постоянное хранение, управляемое контейнером (CMP). Сущностные объекты EJB типа BMP должны реализовывать код доступа к данным, в то время как в объектах типа CMP эта функция реализуется контейнером. Реализации контейнера CMP обычно предоставляются для случая, когда постоянные данные хранятся в реляционной базе данных, хотя возможны и другие способы постоянного хранения (объектная база данных, файлы и т.п.).

Дополнительная информация о сущностных объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.1 на Web-сайте http://java.sun.com/. Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans.

Управляемые сообщениями объекты EJB

Компонент управляемого сообщением объекта EJB предоставляет службу, реализующую бизнес-логику обработки сообщений. Эту службу может вызывать только контейнер; клиент не может напрямую вызывать эту службу через удаленные или локальные интерфейсы. Вместо этого, когда сообщение поступает в место назначения или конечную точку, обслуживаемую объектом EJB, контейнер вызывает экземпляр управляемого сообщениями объекта EJB, присвоенного как MessageListener месту назначения. Экземпляры управляемых сообщениями объектов EJB не обслуживают диалоговое состояние, но могут обслуживать переменные экземпляров со ссылками на ресурсы (например, соединение с базой данных) в вызовах методов.

Примечание: управляемые сообщениями объекты EJB не поддерживаются в версиях до EJB 2.0. Поддержка типов сообщений, отличных от JMS, - это новая функция спецификации EJB 2.1, поэтому они не поддерживаются в предыдущей версии.

Дополнительная информация об управляемых сообщениями объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.0 на Web-сайте http://java.sun.com/. Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans.

Сравнительное описание объектов JavaBean и EJB

Несмотря на схожесть названий, объекты EJB значительно сложнее, чем обычные объекты JavaBean. И те, и другие определяют архитектуры для многоразовых компонентов, но объекты EJB добавляют необходимую поддержку для создания распределенных, многопользовательских служб. Собирать оба типа компонентов можно с помощью инструментов компоновки приложений, но для выполнения объекты EJB необходимо развертывать в контейнере EJB.

Службы (API) для компонентов J2EE

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

Сборка и развертывание

Приложения J2EE состоят из файла описания приложения (application.xml) и одного или нескольких модулей J2EE, образующих приложение. Модули являются многоразовыми, переносимыми компонентами. Приложения J2EE упаковываются в архивы .ear.

Файлы описания

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

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

Модули J2EE

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

• Элементы, не относящиеся к Java, развернутые на Web-сервере (страницы JSP, файлы изображений, статические страницы HTML); иными словами, элементы виртуальных каталогов
• Элементы Java, развернутые на Web-сервере (сервлеты, объекты JavaBean, классы Java)
• Элементы, развернутые на сервере EJB (объекты EJB и поддерживающие классы Java)

Существует три вида модулей J2EE:

• Приложение-клиент J2EE
• Web-компонент
• Enterprise JavaBean

Приложение-клиент J2EE

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

• файл описания application-client.xml
• файлы .class реализации приложения-клиента

Web-компонент

Модули Web-компонента упаковываются в архивы .war и содержат:

• файл описания web.xml и файлы описания для конкретных серверов
• страницы JSP
• страницы HTML
• изображения (например, .gif и .jpg)
• файлы классов сервлетов

Если модуль - это Web-служба, то архив .war содержит:

• файл описания webservices.xml
• файлы классов сервлетов
• файлы WSDL

Enterprise JavaBean

Отдельный архив JAR Enterprise JavaBean может содержать несколько объектов EJB, но их информация развертывания хранится в одном наборе файлов описания (ejb-jar.xml плюс файлы описания для конкретных серверов).

Стандартный модуль Enterprise JavaBean содержит:

• файл описания ejb-jar.xml и файлы описания для конкретных серверов
• файлы классов реализации EJB

Модуль Enterprise JavaBean Web-службы содержит:

• файл описания webservices.xml
• файлы классов реализации EJB

Дополнительная информация об упаковке и развертывании J2EE приведена на Web-сайте http://java.sun.com/. Выберите ссылку Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program.

Разработка приложений J2EE

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

Роли для разработки приложений J2EE

Роли для разработки приложений перечислены в следующей таблице.

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

Этапы разработки приложения J2EE

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

• Разработка компонентов
• • Создание приложения-клиента J2EE
  • Создание Web-компонента
  • Создание объекта Enterprise JavaBean
  • Сборка приложения J2EE
  • Разработка приложения J2EE

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

  В следующей таблице приведены этапы разработки приложений J2EE.

  Этап разработки J2EE	Задачи	Выполняющая задачу роль J2EE	Результат (доставляемый объект)
  Создание приложения-клиента J2EE	Создает код клиента и компилирует классы Создает файл описания application-client.xml Создает архив файлов JAR, содержащий файлы классов и XML	Провайдер компонентов приложений (разработчик программного обеспечения)	Файл JAR, содержащий приложение-клиент J2EE
  Создание Web-компонента	Создает код сервлета и компилирует классы Создает страницы JSP и HTML Создает файл описания web.xml Создает архив файлов Web Application Archive (WAR), содержащий файлы классов, .jsp, .html и XML	Провайдер компонентов приложений (разработчик программного обеспечения: сервлеты; проектировщик Web: страницы JSP и страницы HTML)	Файл WAR, содержащий Web-компонент
  Создание объекта Enterprise JavaBean	Создать код EJB и откомпилировать классы Создать файл описания ejb-jar.xml и файлы описания для конкретных серверов Создать архив файлов JAR, содержащий файлы классов и XML	Провайдер компонентов приложений (разработчик программного обеспечения)	Файл JAR, содержащий объект Enterprise JavaBean
  Сборка приложения J2EE	Создать файл описания application.xml Создать архив файлов EAR, содержащий объекты EJB (JAR), Web-компоненты (WAR) и файлы XML	Ассемблер приложений	Файл EAR, содержащий приложение J2EE
  Развертывание приложения J2EE	Добавить приложение J2EE (EAR) в среду сервера J2EE Отредактировать файл описания application.xml с локальной конфигурацией среды Развертывает приложение J2EE на сервере J2EE	Средство развертывания	Установленное и настроенное приложение J2EE

  
  

  Каждый этап процесса разработки создает доставляемый объект, используемый на следующем этапе. Компоненты, создаваемые на этапах разработки компонентов, используются на этапе сборки приложения J2EE для создания архива EAR приложения J2EE. На этапе развертывания приложения J2EE архив EAR развертывается на сервере J2EE.

  Доставляемые объекты каждого этапа переносимы и не обязательно должны выполняться теми же пользователями или даже в той же среде; среда должна лишь удовлетворять требованиям платформы J2EE.

  Дополнительная информация об упаковке и развертывании J2EE приведена на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints.

  Дополнительная информация

  Дополнительная информация о J2EE приведена в документе Sun J2EE Blueprints. Его можно найти на Web-сайте http://java.sun.com/. Выберите ссылку J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition.

  Копия этого документа содержится также в Rational Unified Process.

  Главы документа Sun J2EE Blueprints, содержащие информацию по конкретным темам, указаны в следующей таблице.

  Концепция J2EE	Глава J2EE Blueprints
  Технологии платформы J2EE	Глава 2
  Объекты Enterprise JavaBean	Глава 5
  Транзакции	Глава 8
  Защита	Глава 9
  Сервлеты	Глава 4
  Страницы JSP	Глава 4
  Развертывание и упаковка	Глава 7