tpip

161

Подготовка к созданию среды разработки

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

Подготовка к созданию тестовой среды

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

Подготовка к созданию рабочей среды

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

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

Для того чтобы порталу были доступны все ресурсы системы, рабочая система должна быть полностью выделена порталу, то есть в ней не должны работать серверы, не связанные с порталом.

Рекомендации по созданию кластеров

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

Рабочая версия документа. Не для публикации.

162

Рис. 8.2. Пример кластера WebSphere Portal

Горизонтальная кластеризация подразумевает использование нескольких серверов. Вертикальная кластеризация – исполнение нескольких экземпляров сервера портала на одном физическом сервере с несколькими процессорами - позволяет более оптимально загружать процессоры.

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

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

8.3.Сценарии установки

Всостав WebSphere Portal входит множество продуктов и компонентов, из которых можно выбрать подмножество, отвечающее требованиям конкретной бизнес-среды.

Рабочая версия документа. Не для публикации.

163

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

Сценарий «Быстрая установка»

Рис. 8.3. Сценарий «Быстрая установка»

Этот сценарий ориентирован на установку только WebSphere Portal без дополнительных компонентов. После успешной установки и настройки WebSphere Portal, можно добавить требуемые дополнительные компоненты.

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

Сценарий «WebSphere Portal с расширенными функциями защиты»

Этот сценарий ориентирован на применение WebSphere Portal с внешним администратором защиты, например, Tivoli Access Manager, позволяющим расширить возможности идентификации или проверки прав доступа.

Рабочая версия документа. Не для публикации.

164

Рис. 8.4. Сценарий «WebSphere Portal с расширенными функциями защиты»

Существует также сценарии и без установки внешнего администратора защиты. Тогда аутентификация и авторизация пользователей будет осуществлятся сервером приложений с использованием каталога LDAP.

Сценарий «Локальная среда разработки портлетов с возможностью отладки»

Этот сценарий ориентирован на установку Rational Application Developer и WebSphere Portal для развертывания портлетов.

Рабочая версия документа. Не для публикации.

165

Рис. 8.6. Сценарий «Локальная среда разработки портлетов с возможностью отладки»

Другие сценарии установки

Остальные сценарии установки описаны в документации WebSphere Portal InfoCenter [1] .

8.4. Развертывание портала

Развертывание WebSphere Portal требует тщательного планирования, занимает много времени, состоит из множества этапов и задействует одну или несколько сред развертывания. Таким образом, развертывание портала включает в себя установку портала по нескольким сценариям.

Этапы процесса развертывания

Далее перечислены основные этапы развертывания и рассмотрены различия между ними:

–Пробная установка и демонстрация;

–Разработка приложений и портлетов;

–Подготовка и тестирование;

–Переход к рабочей среде.

Этап «Пробная установка и демонстрация»

Данный этап предназначен для определения направления дальнейшего развертывания WebSphere Portal. На этом этапе необходимо проверить и протестировать функции и утилиты WebSphere Portal, чтобы выяснить, как наилучшим образом использовать WebSphere Portal для решения поставленной задачи.

Основные действия разработчиков:

•Работа с приложениями, поставляемыми вместе с WebSphere Portal;

•Работа с темами и оболочками, предусмотренными в WebSphere Portal;

•Работа со средой разработки WebSphere Portal.

Рабочая версия документа. Не для публикации.

166

Этап «Разработка приложений и портлетов»

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

Основные действия разработчиков:

–Создание новых приложений и разработка нового внешнего вида портала;

–Модификация существующих приложений;

–Полнофункциональное тестирование приложений и внешнего вида тем и оболочек;

–Работа со средой разработки WebSphere Portal.

Этап «Подготовка и тестирование»

На этом этапе происходит полное тестирование новых и существующих приложений и портлетов перед их развертыванием в WebSphere Portal.

Основные действия разработчиков:

–Перенос приложений и тем и оболочек портала из среды разработки в среду интеграции (см. ниже);

–Тестирование интеграции, функциональности и приемлемости;

–Перенос WebSphere Portal в промежуточную систему (см. ниже);

–Всестороннее тестирование приложений портала и элементов оформления в промежуточной среде, имитирующей рабочую среду;

Данный этап предусматривает участие разработчиков портала и портлетов.

Этап «Переход к рабочей среде»

На этом этапе приложения и портлеты, прошедшие тестирование, переносятся в рабочую среду.

Основные действия разработчиков:

Рабочая версия документа. Не для публикации.

167

–Перенос приложений и параметров внешнего вида из промежуточной в рабочую среду;

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

8.5.Настройка сред разработки, интеграции

ипереход к рабочей среде

Применяемые среды

На рисунке показано типичная структура организации сред (систем) разработки, интеграции и промежуточных систем.

Рис. 8.7. Структура организации сред разработки и эксплуатации портала

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

Рабочая версия документа. Не для публикации.

168

такие задачи, как тестирование рабочей нагрузки и подготовка к переходу к рабочей среде могут выполняться в разных системах, обеспечивая тем самым дополнительное разделение обязанностей групп предприятия). Различие фактического числа систем, применяемых заказчиком, и систем, описанных в этом разделе, не влияет на ход процесса подготовки и используемые инструменты.

Среда разработки

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

Рис. 8.8. Среда разработки на одной рабочей станции

Рабочая версия документа. Не для публикации.

169

Рис. 8.9. Среда разработки и тестовая среда на разных рабочих станциях

Таким образом, в среде разработки устанавливается оболочка разработки Rational Application Developer и базовая конфигурация портала для отладки портлетов. При этом портал может быть установлен либо на рабочей станции разработчика, либо на отдельном сервере.

Среда интеграции

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

Рабочая версия документа. Не для публикации.

170

Рис. 8.10. Среда интеграции

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

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

Тестовая (промежуточная) среда

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

Рабочая версия документа. Не для публикации.