Введение

Сборка модуля J2EE приводит к созданию следующих элементов реализации:

• Архив J2EE (файлы WAR, EJB-JAR и JAR) и его
• Файлы описания (файлы XML), описывающие содержимое архива и предполагаемый способ функционирования его компонентов в контейнере развертывания

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

Определение архива

На этом шаге провайдер компонентов приложения идентифицирует компоненты, подлежащие упаковке в модуль.

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

Определение файлов описания

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

Каждый архив содержит стандартный файл описания J2EE; кроме того, он может содержать файлы описания, поставляемые конкретными вендорами. Стандартные файлы описания, ejb-jar.xml для EJB-JAR и web.xml для WAR, содержат разделы, которые необходимо заполнить при тестировании и прочих "нерабочих" типах развертывания, а также раздел, который будет подготовлен окончательным ассемблером приложений для рабочего развертывания.

Каждый файл описания содержит информацию, предназначенную для провайдеров компонентов приложения, а также ассемблеров приложения. Например, файл ejb-jar.xml включает три основных раздела (применительно к обсуждаемой теме): <enterprise-beans>...</enterprise-beans>, <relationships>...</relationships> и <assembly-descriptor>...</assembly-descriptor>. Провайдер компонентов приложения определяет свойства объектов EJB, например поля CMP, в разделе <enterprise-beans>...</enterprise-beans>. Провайдер компонентов приложения также определяет необязательные взаимосвязи между объектами EJB в разделе <relationships>...</relationships> . В разделе <assembly-descriptor>...</assembly-descriptor>  определяются транзакции, роли защиты, права доступа методов и т.п. Обычно этот раздел используется только ассемблером приложения. Ассемблер может изменить содержимое двух других разделов, но это встречается нечасто. Ситуация с архивами WAR аналогична. Дополнительная информация о сборке приложений приведена в разделе Указания: сборка приложений J2EE.

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

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

Проверка архива

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