Герасимов В.В. Технологии построения интеренет-порталов

Подождите немного. Документ загружается.

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

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. Сценарий «Локальная среда разработки портлетов с возмож-

ностью отладки»

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

Остальные сценарии установки описаны в документации Web-

Sphere 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. Среда интеграции

Система интеграции должна иметь доступ ко всем идентифика-

торам администраторов и всем группам пользователей. Для этого сис-

тему интеграции необходимо связать с каталогом пользователей рабо-

чей системы, либо скопировать содержимое этого каталога в локаль-

ный каталог пользователей системы интеграции. При необходимости

для этих систем можно указать разные пароли.

Таким образом, система интеграции позволяет проводить пер-

вичную отладку разработанных приложений портала.

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

Модель промежуточной среды полностью соответствует модели

рабочей системы. Как правило, в них применяются одинаковые опе-

рационные системы и аналогичные аппаратные платформы. Проме-

жуточная система может быть несколько меньше рабочей по аппарат-

ным возможностям (меньшая частота процессоров, меньшее количе-

ство памяти и т.д.). Однако ее архитектура состоит из тех же элемен-

тов, на основе которых создана рабочая система. С точки зрения рабо-

ты эти системы должны быть максимально сопоставимы.