tpip

51

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

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

–Применение окончательно сформированного портала в деловой рабочей среде.

4.4. Среды разработки и эксплуатации

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

Рис. 4.2. Организация систем, участвующих в разработке портала

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

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

52

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

Система разработки

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

Система разработки, как правило, интегрируется с ПО для разработки (Eclipse и др.), что позволяет отлаживать разрабатываемые приложения непосредственно на сервере портала.

Рис. 4.3. Структура системы разработки

Действия команды для развертывания системы

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

Интеграционная система

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

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

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

53

Рис.4.4. Структура интеграционной системы

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

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

Действия команды для развертывания системы

Оператор портала: установка портала (а также основная настройка); выполнение необходимых задач настройки портала.

Промежуточная система

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

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

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

54

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

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

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

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

55

Рис. 4.5. Структура промежуточной и рабочей системы

Действия команды для развертывания системы

Оператор портала: установка портальной платформы; выполнение необходимых задач настройки портала (аналогичных задачам настройки рабочей системы).

Рабочая система

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

Действия команды для развертывания системы

Оператор портала: установка портала; выполнение необходимых задач настройки портала.

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

56

Дополнительные задачи, выполняемые в рабочих системах

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

4.5. Выпуски портала

Разделяют два типа выпусков (релизов) портала: начальный и последующие выпуски. Выпуски изначально разрабатываются в системе интеграции, а после переносятся в промежуточную, затем, после полнофункционального тестирования и проверки, в рабочую систему.

Создание начального выпуска портала

Начальный выпуск портала разрабатывается в системе интеграции. Группа разработчиков предоставляет необходимые объекты, а группа администраторов – конфигурации. Полученные конфигурации и объекты, объединенные в системе интеграции, образуют начальный выпуск портала. Менеджер выпусков на основе начального выпуска создает пакет, который отправляется рабочей группе для установки в промежуточной и рабочей системах.

Перенос начального выпуска портала

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

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

57

Рис. 4.6. Перенос начального выпуска портала

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

Создание последующих выпусков портала

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

Перенос последующих выпусков портала

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

58

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

Рис. 4.7. Перенос последующих выпусков портала

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

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

59

Карта памяти

Вопросы для самоконтроля

1.Опишите процесс управления конфигурацией портала.

2.Перечислите основные роли разработчиков портала и прочих членов команды.

3.Перечислите этапы процесса развертывания выпуска портала и системы, которые задействуются в этом процессе.

4.В чем отличия между процессом развертывания начального и процессом развертывания последующих выпусков портала?

Литература и ресурсы Интернет

5.WebSphere Portal Information Center http://publib.boulder.ibm.com/pvc/wp/510/ent/ru/InfoCenter/i ndex.html

6.Построение корпоративных порталов на базе IBM Web-

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

60

http://www.ibm.com/ru/software/websphere/products/ws_port al.pdf

ГЛАВА 5. ОБЗОР СУЩЕСТВУЮЩИХ ПОРТАЛЬНЫХ ПЛАТФОРМ

В обзор существующих портальных платформ были выбраны не только предложения наиболее известных и авторитетных в области порталостроения фирм разработчиков, таких как IBM, Oracle, Sun, Microsoft, но и бесплатные платформы, такие как Drupal и PHP-Nuke.

5.1. Обзор платформы Drupal

Портальная платформа Drupal [1] может быть использована для построения самых различных типов порталов. Она является свободным программным обеспечением с открытым кодом, под лицензией GNU. В базовой поставке возможности платформы наиболее ориентированы на построение интернет-сообществ: новостных и форумных порталов, блогов и подобных вещей, когда основная задача - не потеряться в массе регулярно поступающих материалов, иметь возможность их структурировать и архивировать для легкого доступа в будущем. Функционал наращивается дополнительными модулями, которые можно доустанавливать по мере необходимости. «Из коробки» платформа предлагает следующие решения:

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

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

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

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