(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Управление зависимостями при миграции приложений и в новых приложениях для WebSphere Application Server V8

Источник: IBM

В данной статье рассматриваются действия по эффективному управлению корпоративными приложениями с использованием IBM Rational Application Developer V8.0 для IBM WebSphere Application Server V8.0. В ней также предоставляется подробная информация об исследовании поведения WebSphere Application Server при загрузке классов посредством Class Loader Viewer (программа просмотра загрузчика классов). Материал был опубликован в журнале IBM WebSphere Developer Technical Journal.

Введение

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

IBM Rational Application Developer предоставляет единую универсальную среду разработки, удовлетворяющую разнообразным требованиям, - от Web-интерфейсов до серверных приложений, от индивидуальной разработки до коллективной, от Java™-разработки до интеграции приложений. Rational Application Developer является частью платформы IBM Rational Software Development Platform, серии продуктов, основанных на платформе с открытыми исходными кодами Eclipse, предназначенной для создания инструментов разработки приложений. Все продукты семейства Rational для настольных ПК предоставляют единую интегрированную среду разработки (IDE). Эти продукты отличаются плагинами, имеющимися в каждой конфигурации.

Управление зависимостями играет важную роль в сценариях после миграции и при разработке приложений с очень большим количеством JAR-файлов для WebSphere Application Server. Возможны ситуации, когда, например, выполняется миграция кода приложения с конкурирующей платформы, совместимой со спецификациями Java 1.4, на WebSphere Application Server V8, который основан на самых последних спецификациях Java. Если при этом зависимости не упорядочены, могут возникать исключительные ситуации, связанные с классами. Хотя каждый сервер приложений имеет свой собственный способ хранения JAR-файлов приложений, лучше упорядочить эти JAR-файлы, используя возможности, предоставляемые Rational Application Developer и WebSphere Application Server.

В данной статье рассматривается управление зависимостями посредством Rational Application Developer V8.0 и WebSphere Application Server V8.0. Основное внимание уделяется сценариям настройки приложений после их миграции, однако большая часть представленной информации применима и в других ситуациях.

Анализ архитектуры приложения

EAR-файл, сгенерированный инструментарием Rational (рисунок 1), содержит EJB-модуль и Web-модуль с необязательным клиентом приложения, модулем-коннектором и т.д., а также дескрипторы развертывания, идентифицирующие каждый модуль:

  • application.xml
  • ejb-jar.xml
  • web.xml
  • ra.xml.

Рисунок 1. Структура EAR-файла приложения
Рисунок 1. Структура EAR-файла приложения

Поскольку EAR-файл может иметь более одного EJB- и Web-модуля, существует вероятность следующих ситуаций:

  • Некоторые классы приложения дублируются в EJB- и Web-модулях, поскольку используются в обоих.
  • На некоторые JAR-файлы есть ссылки и в EJB, и в Web-модулях, поэтому копии JAR-файлов хранятся в нескольких местах.

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

Во время развертывания приложения или после его миграции, когда EAR-файл перенесен в рабочую область Rational Application Developer, важным шагом является анализ архитектуры приложения для идентификации используемых им библиотек. Приложение может состоять из инфраструктур с открытыми исходными кодами, таких как Struts, Spring, Hibernate и т.д., не считая обычных JSP-страниц, сервлетов и EJB-компонентов. Во многих случаях зависимости этих инфраструктур размещаются только в Web-модуле. Некоторые зависимости, такие как регистратор событий (например, log4j), будут использоваться обоими модулями - EJB и Web. Как упоминалось выше, при этом может происходить дублирование классов в EJB- и Web-модулях, поскольку они используются в обоих. Кроме того, приложение может иметь много JAR-зависимостей для поддержки JAR-файлов инфраструктуры. Эти зависимости имеют внутренние ссылки друг на друга и могут быть важны для выполнения приложения.

Некоторые серверы приложений с открытыми исходными кодами объединяют свои JAR-файлы в EAR-файлы, добавляя лишние зависимости. Одним из примеров является j2ee.jar, который определяет J2EE-классы. Количество этих JAR-файлов можно уменьшить за счет компоновки кода приложения с использованием среды времени исполнения WebSphere Application Server V8.0, предоставляемой с инструментарием Rational. Это можно сделать путем настройки среды времени исполнения сервера приложений в аспектах проекта.

Одним из вариантов является использование для разрешения зависимостей приложения JAR-файлов {APPSERVER_ROOT}/plugins с префиксом javax.j2ee.* и org.apache.*. Это потребует единовременных затрат на перекомпоновку исходного кода. (Имейте в виду, что javax.j2ee.servlet.jar и com.ibm.ws.runtime.jar загружаются во время начальной загрузки сервера.)

После идентификации зависимостей можно приступить к распределению JAR-файлов.

Управление JAR-файлами для Web-модуля

Web-модуль состоит из JSP-страниц и сервлетов, которые могут быть расширены стандартными библиотеками шаблонов (JSTL и т.д.), инфраструктурами MVC и ORM (Struts, Hibernate и т.д.), XML-инфраструктурами, Web-сервисами и т.д. В зависимости от способа использования библиотек количество JAR-файлов может увеличиваться экспоненциально, поэтому требуются специальные меры по управлению. Эти JAR-файлы обычно хранятся в каталоге WEB-INF/lib (рисунок 2) и загружаются загрузчиком классов WAR по умолчанию. JAR-файлы можно поместить в эту папку при помощи Rational Application Developer. Позднее мы обсудим, сколькими JAR-файлами можно управлять.

Рисунок 2. Каталог WEB-INF/lib
Рисунок 2. Каталог WEB-INF/lib

Управление зависимостями для EJB-модулей

Java-архивы, на которые ссылаются классы в EJB-модулях, могут храниться в общей библиотеке EAR-уровня, которую можно создать при помощи Rational Application Developer. Для импорта внешних JAR-файлов как общей библиотеки EAR-уровня необходимо импортировать их как Java EE-файлы Utility Jar. Для этого:

  1. Щелкните правой кнопкой мыши на EAR в Rational Application Developer и выберите Import > Java EE Utility Jar (см. рисунок 3).

    Рисунок 3. Вариант JavaEE Utility Jar
    Рисунок 3. Вариант JavaEE Utility Jar

  2. Отметьте переключатель Copy utility jar into existing EAR from external location (см. рисунок 4) и нажмите кнопку Next.

    Рисунок 4. Копирование файла Utility Jar в существующий EAR из внешнего источника
    Рисунок 4. Копирование файла Utility Jar в существующий EAR из внешнего источника

  3. Выберите JAR-файл (см. рисунок 5) и нажмите кнопку Finish. После завершения импорта вы должны увидеть папку lib, созданную в EAR (рисунок 6).

    Рисунок 5. Выбор внешних jar-файлов
    Рисунок 5. Выбор внешних jar-файлов

    Рисунок 6. Папка lib, созданная после завершения импорта
    Рисунок 6. Папка lib, созданная после завершения импорта

Зависимости на EAR-уровне видимы как для EJB-, так и для Web-модуля. Поэтому JAR-файлы пользовательского приложения, которые совместно используются несколькими модулями, можно вместе со сторонними JAR-файлами поместить в это место, следуя описанным выше инструкциям.

Совместное использование классов приложения несколькими модулями

Возможны сценарии, когда EAR-файл приложения имеет дублирующиеся Java-классы в EJB- и Web-модулях. Эти дублирующиеся классы могут храниться в отдельном общем модуле, т.е. Utility-модуле (вспомогательный Java-модуль). В Rational Application Developer можно создать Utility-модуль внутри EAR, выбрав File > New > Other... > Java EE > Utility Project (см. рисунок 7).

Рисунок 7. Выбор проекта Utility-модуля
Рисунок 7. Выбор проекта Utility-модуля

Присвойте имя проекту Utility Project и свяжите его с существующим EAR-файлом (см. рисунок 8). При этом в EAR создастся папка lib. Если папка lib уже существует (например, после импорта JAR-файлов описанным выше способом), Utility-модуль будет скопирован как JAR-файл в эту папку после экспорта EAR.

Рисунок 8. Присвоение имени проекту Utility Project
Рисунок 8. Присвоение имени проекту Utility Project

Для совместного использования классов несколькими модулями скопируйте все Java-классы вместе со всей иерархией в папку src данного проекта Utility-модуля (см. рисунок 9).

Рисунок 9. Классы в общем проекте Utility-модуля
Рисунок 9. Классы в общем проекте Utility-модуля

Рисунок 10. Папка lib в EAR
Рисунок 10. Папка lib в EAR

Рисунок 11. Содержимое папки lib
Рисунок 11. Содержимое папки lib

Рисунок 12. Классы в jar-файле SharedClassesUtility
Рисунок 12. Классы в jar-файле SharedClassesUtility

Для компоновки кода в других модулях (Web и EJB), ссылающихся на общий Utility-модуль, можно добавить ссылку на него в каждый модуль, из которого нужно обращаться к его классам (рисунок 13).

Рисунок 13. Ссылка на общий Utility-модуль в других модулях
Рисунок 13. Ссылка на общий Utility-модуль в других модулях

На рисунках 14 и 15 показан порядок загрузки классов сервером WebSphere Application Server для конкретного EAR.

Рисунок 14. Классы, видимые для Web-модуля
Рисунок 14. Классы, видимые для Web-модуля

Рисунок 15. Классы, видимые для EJB-модуля
Рисунок 15. Классы, видимые для EJB-модуля

Управление дополнительными зависимостями вне EAR

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

Для создания общей библиотеки создайте папку где-нибудь в файловой системе (желательно в {APPSERVER_ROOT}) и укажите ее местоположение в поле Classpath Environment > Shared libraries (рисунок 16).

Рисунок 16. Настройка общей библиотеки
Рисунок 16. Настройка общей библиотеки

После настройки можно связать общую библиотеку с приложением, выбрав Applications > Enterprise Applications > {Application Name} > Shared library references и связав ее с либо EAR-, либо с Web-модулем (рисунок 17).

Рисунок 17. Связывание общей библиотеки с EAR
Рисунок 17. Связывание общей библиотеки с EAR

Поведение загрузчика классов

Теперь посмотрим, как можно использовать программу просмотра загрузчика классов, доступную в консоли администратора WebSphere Application Server, для исследования поведения загрузчика классов во время исполнения. Эта информация полезна при решении проблем, связанных с загрузкой классов. Есть два вида загрузчиков классов, играющих важную роль на сервере WebSphere Application Server. Загрузчик классов приложения группирует EJB-модули (Enterprise JavaBean™), общие библиотеки, архивы адаптера ресурсов (RAR-файлы) и JAR-файлы зависимостей, связанные с приложением. JAR-файлы зависимостей - это JAR-файлы, содержащие код, который могут использовать корпоративные bean-компоненты и сервлеты. Загрузчик классов приложения является родителем загрузчика классов архива Web-приложения (WAR). По умолчанию Web-модуль имеет свой собственный загрузчик WAR-классов, который используется для загрузки содержимого Web-модуля. Значение политики загрузчика WAR-классов загрузчика классов приложения определяет, используется ли для загрузки содержимого Web-модуля загрузчик WAR-классов или загрузчик классов приложения.

Рисунок 18. Диаграмма иерархии загрузчиков классов
Рисунок 18. Диаграмма иерархии загрузчиков классов

По умолчанию в качестве политики загрузчика классов на уровне сервера, связанной с WebSphere Application Server V8.0, используется Multiple with parent class loader first (несколько, сначала родительский загрузчик классов). Это означает, что каждый EAR получает свой собственный загрузчик классов и в каждом приложении библиотеки EAR-уровня загружаются первыми, а за ними следуют Web-библиотеки.

Для анализа поведения загрузчика классов при помощи Class Loader Viewer мы будем использовать библиотеку log4j и проследим его поведение для политик загрузки классов при загрузке в EJB-модуль, Web-модуль или в оба модуля. Class Loader Viewer можно вызвать в консоли администратора, выбрав Troubleshooting > Class loader viewer > server1 > {ВАШЕ ПРИЛОЖЕНИЕ}.

Поведение загрузчика классов с PARENT_FIRST

Сначала загружаются библиотеки приложения, а затем Web-библиотеки. JAR-зависимости помещаются в WEB-INF/lib, если будут использоваться только классами Web-модуля, тогда как созданные разработчиком откомпилированные Java-классы помещаются в WEB-INF/classes. Рассмотрим два случая:

Обнаружение дублирующихся и имеющих несколько версий JAR-файлов

Две версии одной и той же библиотеки, помещенные в одни и те же или разные места EAR, могут привести к конфликтам классов, таким как проблемы разных версий. Предположим, например, что на EAR-уровне имеется версия 1 JAR-файла, содержащая метод f(), а на Web-уровне имеется версия 3 этого же JAR-файла, содержащая метод f(String), а метод f() удален за ненужностью. Если класс приложения пытается обратиться к f(String), он получает ошибку java.lang.NoSuchMethodError, поскольку классы в Web-модуле могут видеть только JAR-файлы, загруженные загрузчиком классов приложения, который не имеет метода f(String). Для контроля этой ситуации на уровнях EAR- и Web-модуля хранятся и проверяются при помощи Class Loader Viewer две версии log4j (см. рисунок 21).

Рисунок 21. Обнаружение дублирующихся JAR-файлов
Рисунок 21. Обнаружение дублирующихся JAR-файлов

Поведение загрузчика классов с PARENT_LAST

Если настройки загрузки классов меняются на PARENT_LAST, загрузчику Web-классов дается приоритет перед загрузчиками классов приложения. В этом случае Web-приложения не могут видеть классы, доступные на EAR-уровне. Рисунок 22 показывает, что ../WEB-INF/lib/log4j.jar загружается до ../TestApp.ear/lib/log4j-1.2.16.jar (сравните с рисунком 21).

Рисунок 22. Политика загрузчика классов Parent Last
Рисунок 22. Политика загрузчика классов Parent Last

Тестирование сценариев приложения

Тест видимости зависимостей

Контрольный тест, содержащийся в материалах для загрузки, демонстрирует конфигурацию библиотеки log4j и общего Utility-модуля, который может вызываться из классов приложений, основанных как на EJB-, так и на Web-модулях. Для записи отдельных log-файлов из EJB- и Web-модулей создаются два файла свойств log4j. Эти файлы свойств хранятся в специальной папке {PROFILE_ROOT}/log4jProperty (см. рисунки 23 и 24). Чтобы log4j.jar был виден классам во всех модулях EAR, он хранится в библиотеке EAR-уровня.

Рисунок 23. Папка файлов свойств log4j
Рисунок 23. Папка файлов свойств log4j

Рисунок 24. Файлы свойств log4j
Рисунок 24. Файлы свойств log4j

Соответствующие файлы свойств загружаются в соответствующие модули, как показано на рисунках 25 и 26.

Рисунок 25. Загрузка файла свойств в EJB
Рисунок 25. Загрузка файла свойств в EJB

Рисунок 26. Загрузка файла свойств в сервлет
Рисунок 26. Загрузка файла свойств в сервлет

Поскольку библиотеки log4j используются в обоих модулях (EJB и Web), зависимости должны храниться так, чтобы быть видимыми в обоих модулях (рисунок 27).

Рисунок 27. Сгенерированные log-файлы
Рисунок 27. Сгенерированные log-файлы

Тест общего Utility-модуля

Этот тест демонстрирует совместное использование общих классов приложения в нескольких модулях. Для тестирования мы разработали класс TestSharedUtility, который можно успешно вызвать из EJB и Web-модулей и зарегистрировать ответ (см. рисунки 28, 29 и 30).

Рисунок 28. Класс Shared Utility
Рисунок 28. Класс Shared Utility

Рисунок 29. Вызов класса из EJB-модуля
Рисунок 29. Вызов класса из EJB-модуля

Рисунок 30. Вызов класса из Web-модуля
Рисунок 30. Вызов класса из Web-модуля

Тест конфликта классов

Для тестирования конфликтов классов создаются две JAR-зависимости с двумя методами, имеющими одинаковое название, но разные параметры. Предполагается, что метод зависимости 1 устарел и был удален из зависимости 2. Хотя может быть несколько вариантов хранения этих зависимостей, в данном случае зависимость 1 хранится как вспомогательный JAR-файл на EAR-уровне, а зависимость 2 хранится в каталоге WEB-INF/lib. Зная, что зависимость 1 загружается загрузчиком классов приложения, а зависимость 2 загружается загрузчиком Web-классов, рассмотрим поведение при вызове из сервлета (см. рисунки 31 и 32).

Рисунок 31. Сигнатура метода класса Version1
Рисунок 31. Сигнатура метода класса Version1

Рисунок 32. Сигнатура метода класса Version2
Рисунок 32. Сигнатура метода класса Version2

В случае Version2 метод f() был удален. Более старый JAR-файл version1test.jar хранится на EAR-уровне, тогда как более новый JAR-файл version2test.jar хранится в WEB-INF/lib (см. рисунок 33).

Рисунок 33. Местоположение скопированных JAR-файлов
Рисунок 33. Местоположение скопированных JAR-файлов

Результаты, показанные на рисунке 34, предполагают, что тестовый сервлет хочет вызвать метод более нового JAR-файла и что предыдущий JAR-файл хранится на EAR-уровне по ошибке.

Рисунок 34. Вызов новой версии метода
Рисунок 34. Вызов новой версии метода

При выполнении теста классы файла version1test.jar будут видимы сервлету и потому сгенерируют исключительную ситуацию, приведенную в листинге 1.

Трассировка исключительной ситуации

[4/13/12 6:25:10:247 EDT] 00000021 servlet
E com.ibm.ws.webcontainer.servlet.ServletWrapper service Uncaught service() exception 
thrown by servlet com.ibm.test.VersionTestServlet: java.lang.NoSuchMethodError: 
com/ibm/test/TestClass.f(Ljava/lang/String;)Ljava/lang/String;
   at com.ibm.test.VersionTestServlet.doPost(VersionTestServlet.java:41)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
   at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1147)
   at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:
	722)
   at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:
	449)
   at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest
	(ServletWrapperImpl.java:178)
   at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters
	(WebAppFilterManager.java:1020)
   at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3703)
   at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
   at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:953)
   at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1655)
   at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
   at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination
	(Http	InboundLink.java:452)
   at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest
	(HttpInboundLink.java:511)

Устранить исключительную ситуацию можно либо путем удаления файла version1test.jar из EAR и сохранения другого в WEB-INF/lib, либо путем замены version1test.jar на version2test.jar и удаления последнего из WEB-INF/lib, если его классы также нужно вызывать из EJB.

Заключение

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

Загрузка

Описание

Имя

Размер

Метод загрузки

Пример кода 1205_chandra_attachment.zip 525 КБ HTTP 



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 21.11.2012 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User From Rational Clearcase Lt Floating User Trade Up License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM Rational Method Composer Authorized User License
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Программирование на Visual Basic/Visual Studio и ASP/ASP.NET
ЕRP-Форум. Творческие дискуссии о системах автоматизации
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Ищу программиста для написания программы (81)
Ищу программиста ,владеющего Вижуал Бэйсик и программированием в Экселе, для написания...
 
Пишу программы для Windows (в том числе базы данных) (10)
Написание компьютерных программ на заказ. Разработка корпоративных информационных...
 
Нормальные казино в 2021 году (23)
После долгих поисков все таки смог найти хорошие игровухи, хотя и ушла куча времени, пока я...
 
Онлайн казино ПокерДом (7)
Поспешите начинать зарабатывать играя в онлайн казино ПокерДом...
 
Выбор лучшего онлайн казино (16)
Очень важным критерием для составления рейтинга являются честные отзывы клиентов о казино. Люди...
 
 
 



    
rambler's top100 Rambler's Top100