Учебное пособие по J2EE. Обзор
www.javagu.ru
Сегодня все больше и больше разработчиков хотят создавать распределенные транзакционные корпоративные приложения и использовать преимущества в скорости, защищенности и надежности, обеспечиваемые серверными технологиями. Если вы уже работаете в этой области, то вам известно, что в современном, быстро меняющемся и выдвигающем все новые требования мире электронной коммерции и информационных технологий, корпоративные приложения должны проектироваться, создаваться и внедряться за меньшие деньги, с большей скоростью и меньшими затратами ресурсов, чем это было ранее.
Для уменьшения стоимости и увеличения скорости проектирования и разработки корпоративного приложения платформа J2EE предлагает компонентный подход к проектированию, разработке, сборке и внедрению корпоративных приложений. Платформа J2EE предлагает модель многоуровневого распределенного приложения, возможность повторного использования компонентов, интегрированный обмен данными на основе XML, унифицированную модель безопасности и гибкое управление транзакциями. Вы не только можете выпускать на рынок инновационное решение для пользователей быстрее, чем раньше, но и Ваши платформо-независимые, основанные на компонентах J2EE-решения больше не привязаны к продуктам и API какого-либо одного производителя. Производители и пользователи обладают свободой выбора продуктов и компонентов, которые наиболее полно удовлетворяют их деловые и технологические требования.
Это руководство основано на примерах, описывающих возможности и функции, доступные в J2EE SDK версии 1.3. Вне зависимости от того, новичок Вы или опытный корпоративный разработчик, Вы найдете в примерах и сопровождающем их тексте полезную и доступную информацию для создания ваших собственных корпоративных решений.
Если Вы новичок в разработке J2EE приложений, эта глава – хорошее место для старта. В ней вы изучите архитектуру J2EE, ознакомитесь с важными соглашениями и понятиями, а также найдете собственные подходы к программированию, сборке и внедрению J2EE приложений.
В этой главе
Распределенные многоуровневые приложенияJ2EE-компоненты
J2EE-клиенты
Web-компоненты
Бизнес-компоненты
Уровень корпоративной информационной системы
J2EE-контейнеры
Контейнерные сервисы
Типы контейнеров
Пакетирование
Роли в разработке ПО
Поставщик J2EE-продукта
Поставщик инструмента
Поставщик компонента приложения
Компоновщик приложения
Установщик приложения и администратор
Программное обеспечение
Доступ к базам данных
J2EE API
Упрощенная системная интеграция
Инструменты
Распределенные многоуровневые приложения
Платформа 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", доступное на
http://java.sun.com/products/jms/tutorial/index.html
Уровень корпоративной информационной системы
Уровень корпоративной информационной системы образует программное обеспечение информационной системы и включает в себя системы корпоративной инфраструктуры, такие как планирование ресурсов предприятия (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 можно загрузить с
http://java.sun.com/j2ee/download.html#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 на
http://java.sun.com/products/jms/tutorial/index.html
Java Naming and Directory Interface 1.2
JNDI обеспечивает функции имен и каталогов. Интерфейс предоставляет приложениям методы для стандартных операций с каталогами, таких как назначение атрибутов объектам и поиск объектов по их атрибутам. Используя JNDI, J2EE-приложение может сохранять и восстанавливать любые типы именованных Java-объектов.
Поскольку JNDI не зависит от какой бы то ни было специализированной реализации, приложения могут использовать JNDI для доступа к многочисленным сервисам имен и каталогов, включая такие сервисы, как LDAP, NDS, DNS и NIS. Это позволяет J2EE-приложениям сосуществовать с традиционными приложениями и системами. Дополнительную информацию по JNDI можно получить в онлайн-руководстве по JNDI на
http://java.sun.com/products/jndi/tutorial/index.html
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-технология на практике" на
http://java.sun.com/j2ee/inpractice/aboutthebook.html
Инструменты
Реализация J2EE предоставляет средства размещения приложения и набор скриптов для компоновки, проверки и размещения J2EE-приложений, а также управления средой разработки и рабочим окружением. Смотрите приложение В, в котором содержится информация об инструментах.
Инструмент размещения приложения
J2EE-реализация предоставляет инструмент размещения приложения (deploytool) для компоновки, проверки и размещения J2EE-приложений. Существует две версии: командная строка и GUI.
GUI-версия включает мастера для:
Пакетирования, конфигурирования и размещения J2EE-приложений.
Пакетирования и конфигурирования корпоративных компонентов.
Пакетирования и конфигурирования Web-компонентов.
Пакетирования и конфигурирования клиентских приложений.
Пакетирования и конфигурирования адаптеров ресурсов.
Кроме того, информация о конфигурации может быть установлена для каждого типа компонента или модуля на закладке "inspector".
Скрипты
Таблица 1-1 содержит список скриптов, включенных в J2EE-реализацию и позволяющих выполнить действия из командной строки.
Таблица 1. J2EE-скрипты
Скрипт | Описание |
j2ee |
Запуск и остановка J2EE-сервера |
cloudscape |
Запуск и остановка базы данных по умолчанию |
j2eeadmin |
Добавление JDBC-драйверов, JMS-назначений и мастеров соединений для различных ресурсов |
keytool |
Создание общих и персональных ключей и генерация сертификата X509 |
realmtool |
Импорт файлов сертификата. Добавление и удаление J2EE пользователей из списка аутентификации и авторизации для J2EE-приложения |
packager |
Пакетирование компонентов J2EE-приложения в EAR, EJB JAR, JAR и WAR-файлы |
verifier |
Проверка корректности EAR, EJB JAR, JAR и WAR-файлов и соответствия их J2EE-спецификации |
runclient |
Запуск клиентского приложения J2EE |
cleanup |
Удаление всех размещенных приложений с J2EE-сервера |