Подготовка к внедрению IBM PureApplication System: Часть 2. Готово ли ваше приложение к переносу в виртуальную среду?

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

Кайл Браун, заслуженный инженер, IBM

Кайл Браун (Kyle Brown) – фотографияКайл Браун (Kyle Brown), заслуженный инженер IBM, работает в IBM Software Services for WebSphere, специализируясь на сервис-ориентированной архитектуре и смежных технологиях. Кайл занимается консультированием, обучением и инструктированием в области сервис-ориентированной архитектуры, объектно-ориентированных технологий и технологий J2EE клиентов, входящих в список Fortune 500. Он является соавтором книг Программирование на Java с помощью IBM WebSphere (EN) и Персистентность в корпоративных системах (EN). Часто выступает на конференциях по вопросам сервис-ориентированной архитектуры, Enterprise Java, объектно-ориентированного проектирования и шаблонов проектирования.



30.05.2012

Введение

В предыдущей статье Часть 1: обзор адаптируемых приложений (EN) вы узнали, как IBM® PureApplication® System поддерживает виртуальные приложения и виртуальные системы. Если говорить коротко, они отличаются компромиссом между уровнем управления и уровнем автоматизации. В данной статье объясняется, как выбрать наиболее подходящий для конкретного приложения вариант развертывания.


Преимущества и ограничения виртуальных приложений

Виртуальное приложение – это способ развертывания JEE-приложения вместе с набором политик, определяющих варианты масштабирования и использования ресурсов виртуальной машины Java (JVM). При развертывании приложения как виртуального приложения вы получаете также встроенный набор общих сервисов, выполняющих различные задачи, такие как распределение нагрузки и управление сеансами HttpSession.

Однако подобные преимущества автоматизации не даются даром. PureApplication System активно управляет топологией вашего приложения (например, количеством одновременно работающих серверов приложений, выбором сервера для обработки запросов определенного типа и т.д.). Это означает, например, что вы не сможете разделить свое приложение на Web-уровень, выполняющий сервлеты, и EJB-уровень, выполняющий удаленные EJB-компоненты. Для большинства приложений это не проблема, но для более старых приложений, которые были разработаны на основе многоуровневого пакетирования или функциональные возможности которых зависят от конкретной топологии, такой способ развертывания может создать трудности в функционировании. Еще одним ограничением является поддержка только определенных моделей программирования. Для приложений, требующих большей гибкости, PureApplication System предоставляет так называемые виртуальные системы.


Преимущества и ограничения виртуальных систем

Виртуальная система представляет собой механизм, создающий шаблон или схему полной топологии, построенной из виртуальных образов. Для построения собственных виртуальных систем можно использовать предоставляемые компанией IBM образы Hypervisor Edition или взять за основу образ RHEL и использовать программу IBM Tivoli® ICON.

Кроме того, PureApplication System предоставляет функциональность Capture and Extend, которая позволяет добавить дополнительное ПО в имеющийся виртуальный образ и переупаковать его для последующего использования. Еще одним ключевым аспектом создания виртуальных систем является возможность добавления своих собственных сценариев. Чтобы развернуть приложение в созданном вами шаблоне топологии, необходимо создать сценарий развертывания, который станет частью реализации процесса развертывания экземпляра виртуальной системы на аппаратном уровне PureApplication System.


Выбор правильного подхода

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

  1. Создаете ли вы новое приложение?

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

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

  2. Является ли приложение Web-приложением?

    Простота этого вопроса обманчива. На самом деле вопрос звучит так: действительно ли приложение принимает только входящие HTTP- или HTTPs-запросы? Это определение охватывает много различных шаблонов разработки приложений, в частности, следующие варианты:

    • Приложение, предоставляющее RESTful-сервисы к пользовательскому интерфейсу и написанное с использованием технологий Javascript и AJAX.
    • Поставщик Web-сервисов, реализующий SOAP-сервисы для внешних клиентов через Интернет.
    • Классическое Web-приложение, построенное на сервлетах и JSP-страницах.

    Однако такое определение исключает некоторые типы приложений; например, согласно ему клиент-серверное Java-приложение, использующее "толстый" Java-клиент, подключающийся к EJB-компонентам сервера по протоколам RMI или RMI/IIOP, не идентифицируется как Web-приложение. Данное соображение порождает следующий вопрос.

  3. Используются ли удаленные EJB-компоненты?

    EJB-компоненты служат эффективным компонентом модели программирования JEE практически с момента ее появления. Однако преимущество удаленных EJB-компонентов нивелируется сложностью топологии приложения. Сервер приложений должен обрабатывать как входящий HTTP-трафик к сервлетам, JSP-страницам и Web-сервисам, так и входящий RMI/IIOP-трафик от EJB-клиентов. В результате обычно приходится создавать два уровня серверов приложений; один выделяется для обработки HTTP-трафика, а второй – для обработки RMI-трафика. В итоге для упрощения процесса использования виртуальных приложений приходится отказываться от подобных топологических вариантов. Таким образом, как говорилось выше, если необходимы EJB-компоненты, обратите внимание на виртуальные системы, в которых эти варианты топологий доступны.

  4. Упаковано ли приложение стандартным способом?

    Опять же простота этого вопроса обманчива. Фраза "стандартным способом" означает, что приложение должно быть упаковано в EAR-файл, WAR-файл, ZIP-архив или EBA (архив OSGi Enterprise Bundle Archive). Несмотря на то, что стандарт JEE предполагает упаковку приложений в EAR или WAR-файлы, а стандарт OSGi ввел понятие EBA-архивов, многие приложения до сих пор не упаковываются подобным образом, а поставляются в виде "разобранных" структур каталогов. Хотя это подходит для простых серверов, таких как Tomcat, выполнение действий нестандартным способом может привести к сложностям при размещении приложений на новых JEE-серверах, в том числе поддерживающих виртуальные приложения. Поэтому, если ответ на этот вопрос отрицателен, упакуйте ваше приложение заново в один из стандартных форматов. Более того, для сервера WebSphere® Application Server можно использовать много других стратегий упаковки (например, связанные с сервером общие библиотеки). Опять же, для упрощения модели эти стратегии не используются в виртуальных приложениях. Если избежать таких подходов нельзя, обратите внимание на виртуальные системы.

  5. Использует ли приложение стандартные модели программирования JEE?

    Существует старый афоризм: достоинство стандартов состоит в том, что их много и можно выбирать любой. К сожалению, он применим и к моделям программирования. Появляются все новые и новые программные интерфейсы, а Java-сообщество завалено JSR-запросами (запросами на Java- спецификацию), которые никогда не утверждались или никогда не получали достаточного распространения, чтобы войти в стандарт JEE. Проблема снова заключается в том, что при использовании виртуальных приложений мы хотим сохранить простоту. Следовательно, необходимо ограничить набор поддерживаемых программных интерфейсов до разумных пределов. Поэтому, если ваше приложение использует только стандартные программные интерфейсы (JEE5, J2EE1.4, 1.3 или 1.2, OSGI, JPA, JAX-RPC, JAX-WS и JAX-RS), все должно быть хорошо.

    С другой стороны, если вы используете более новый уровень JEE (например, JEE 6) или малоизвестный интерфейс, извлеченный из недр JCP, ваше приложение, вероятно, не будет работать как виртуальное приложение. Было заявлено, что IBM обеспечит поддержку новых программных интерфейсов посредством выпуска пакетов дополнений (Feature Packs). Следовательно, если вы планируете использовать новый уровень интерфейса, рассмотрите возможность создания виртуальной системы на базе WebSphere Application Server V8 и интеграции соответствующего Feature Pack (и поддержки данного интерфейса), когда он будет доступен.

  6. Работает ли приложение в данный момент на сервере WebSphere Application Server Version 7 или Version 8?

    Это простой, но важный вопрос. На него можно ответить по-разному. Даже при положительном ответе на этот вопрос, но отрицательном ответе на один из предыдущих вопросов, касающихся модели программирования, способа упаковки и использования удаленных EJB-компонентов, решение от вас уже не зависит – приложение не может быть виртуальным. Однако если ответ отрицателен, возможность исполнять приложение как виртуальное все равно остается. Если приложение согласуется с вопросами по модели программирования и способу упаковки, ситуация может разрешиться благополучно. Но если приложение выполняется на слишком старой версии сервера WebSphere Application Server или на другом сервере приложений, для миграции на виртуальное приложение или на виртуальную систему, возможно, придется приложить некоторые усилия.

  7. Требует ли приложение наличия каких-либо продуктов семейства WebSphere (например, WebSphere Portal Server или WebSphere Process Server)?

    Как уже говорилось, подход с использованием виртуальных приложений нацелен на создание Web-приложений. Если ваше приложение или рабочая нагрузка не являются Web-приложением, использование виртуального приложения на данный момент вам не подходит. Подчеркну, что это верно только на данный момент. Со временем в IBM Workload Deployer и PureApplication System будут добавлены новые типы рабочих нагрузок. Поэтому рано или поздно вы сможете воспользоваться преимуществами более высокого уровня автоматизации, которые обеспечивает виртуализация для Web-приложений, даже для приложений, предназначенных для управления бизнес-процессами. Однако пока для таких приложений необходимо создать виртуальную систему с интегрированными продуктами IBM Hypervisor Edition, входящими в состав интерактивного каталога для PureApplication System и IBM Workload Deployer.

  8. Готово ли приложение использовать функции управления сеансами при помощи WebSphere Extreme Scale?

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

    Прежде всего, объявляется ли все содержимое HttpSession как java.io.Serializable? Если нет – это проблема. Модель политик масштабирования для виртуальных приложений подразумевает, что экземпляры сервера приложений могут динамически создаваться и уничтожаться в любое время в зависимости от нагрузки. Если вы рассчитываете, что ваш сервер работает постоянно и его память является «надежным» хранилищем данных сеанса, при попытке сделать приложение виртуальным вас ждет разочарование.

    Более того, если сеансы очень велики (сотни мегабайт), вас может неприятно удивить время загрузки сеанса по сети из сегмента WebSphere Extreme Scale. С другой стороны, если сеансы невелики и полностью сериализуемы (что соответствует передовым методикам использования HttpSession), виртуальные приложения использовать можно.

  9. Приложение использует внешние средства обеспечения безопасности или специальные интерфейсы, такие как Trust Authentication Interceptors (TAI) или JAAS-плагины?

    Наконец, следует рассмотреть требования к безопасности приложения. Если такие требования не предъявляются или используется WebSphere Security и один из поддерживаемых реестров пользователей (TDS, Microsoft® Active Directory), значит, систему можно реализовать в виде виртуального приложения. С другой стороны, если используется автономное средство обеспечения безопасности (например, Tivoli Authentication Manager), какой-либо его конкурент или специализированная функциональность WebSphere Security (например, JAAS или TAI), следует планировать создание виртуальной системы.


Выбор правильного подхода в нужное время

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


Планы на будущее

Лучший способ выяснить, готово ли приложение к работе в качестве виртуального – просто потратить время на этот процесс. К счастью, IBM готова помочь вам в этом. Процесс PureExperience состоит из нескольких шагов, детализирующих наши вопросы. Задавая вам вопросы и получая на них ответы, технический специалист IBM по работе с клиентами поможет вам понять, какая модель наиболее подходит для конкретного приложения. В свою очередь, подразделение IBM Software Services for WebSphere поможет выполнить миграцию и внедрить PureApplication System. Детальную информацию можно получить у торговых представителей IBM.


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=816993
ArticleTitle=Подготовка к внедрению IBM PureApplication System: Часть 2. Готово ли ваше приложение к переносу в виртуальную среду?
publish-date=05302012