Архитектура и компоненты портала
При организации общих служб многие реализации порталов используют схожие архитектурные концепции, в том числе портлеты, платформы серверов порталов и интеграция портала с удаленными портлетами.
Портлеты и контейнеры портлетов
Информационное наполнение часто предоставляется пользователям в форме так называемых портлетов — своеобразных контейнеров, которые, по существу, являются пользовательским представлением соответствующего им персонифицированного информационного наполнения. С технической же точки зрения, портлет — это фрагмент кода, который исполняется на сервере порталов и позволяет встраивать информационное наполнение в страницы портала.
В данной статье речь о портлетах и контейнерах портлетов ведется в терминах J2EE, поскольку данная платформа поддерживает и структуру портлетов, и взаимодействие портлетов со средой времени исполнения. Кроме того, большинство реализаций серверов порталов — это Web-приложения на базе J2EE.
J2EE — одна из самых известных серверных компонентных моделей. В J2EE серверные компоненты размещаются в специальных контейнерах. Контейнер представляет собой среду времени исполнения для серверного компонента; он вызывает компонент и предоставляет специфические для компонента службы (например, информация о пользователе и сохранение состояния объекта между сеансами).
Точно так же портлеты размещаются в контейнерах портлетов. API портлетов определяет интерфейс между портлетом и контейнером портлетов.
 | |
|
Рис. 2. Простой портлет. Здесь приведена реализация портлета, подготовленная для среды Apache Jetspeed |
На рис. 2 показана простая реализация портлета. Как и сервлет, портлет существует в единственном экземпляре, который создается один раз в контейнере портлетов, а затем может многократно использоваться в различных нитях управления. В состав API портлетов входят следующие элементы:
Портлеты существуют в нескольких режимах. Пользователи могут видеть представленное информационное наполнение, запускать службу помощи для конкретного представления или редактировать представление таким образом, чтобы настроить его в соответствии со своими предпочтениями, а администраторы могут конфигурировать портал для предоставления настроенных служб. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Кроме того, представление может находиться в одном из нескольких состояний, в том числе normal («нормальное»), maximized («максимизированное»), minimized («минимизированное»), closed («закрытое») и т.д. Как и дескрипторы размещения сервлетов, дескрипторы портлетов содержат свойства, существенные для размещения конкретного портлета.
В дополнение к контейнеру портлетов сервер порталов должен предоставлять службу получения информационного наполнения и службу сохранения состояния между сеансами, которые позволяют портлетам хранить информацию в специальном буфере. Однако самая важная служба портлета — это служба пользовательской информации, которая дает портлетам доступ к информации, касающейся пользователей, в том числе предпочтения, данные о настройке и т.д.
 |
Рис. 3. Строительные блоки сервера порталов. |
Удаленные портлеты
Порталы получают информацию и информационное наполнение из многих источников, в том числе из внутренних систем и от провайдеров приложений и информационного наполнения на базе Internet.
Чтобы интегрировать новый источник, владелец портал должен адаптировать информационное наполнение к формату, который воспринимается порталом, что может оказаться весьма длительным и трудоемким процессом.
Процесс интеграции можно упростить одним из двух способов. При первом подходе внешние провайдеры услуг поставляют информационное наполнение в формате, который непосредственно воспринимается клиппирующим портлетом (как правило, HTML или WML). Однако этот подход ограничивает возможности портала готовить информационное наполнение в соответствии с особенностями конкретного канала взаимодействия с пользователем. При втором подходе владелец портала устанавливает портлет на сервере порталов внешнего провайдера услуг. Затем портлет получает информационное наполнение в своем особом формате для вывода его как части общей страницы портала. Однако размещение кода независимого поставщика на сервере может оказаться небезопасным как с точки зрения стабильности, так и с точки зрения защиты информации. Например, портал для сотрудников может предоставить доступ к размещаемой в Internet информации о погоде и приложению управления кадрами в системе планирования ресурсов предприятия. Чтобы предоставить такой доступ, администратор запускает портлеты локально, как показано на рис. 4.
 |
Рис. 4. Портлеты работают на локальном сервере порталов. В этом случае кадровый портал предоставляет пользователям доступ к Internet-службе погоды и кадровым приложениям из внутренней ERP-системы |
Модуль исполнения портлетов обладает функциональностью, достаточной для того, чтобы дать возможность удаленному портлету реагировать на вызовы посредника портлета. Таким образом, посредник портлета не нуждается в таких службах, как объединение и настройка. Модуль исполнения портлетов может также быть реализован в другой технологии (например,.Net), если она поддерживает протокол удаленного вызова портлетов, поддерживаемый посредником портлета.
Чтобы обеспечить интероперабельность между различными серверами порталов и поставщиками информационного наполнения, необходима стандартизованная модель взаимодействий для посредника портлета и удаленного портлета. В настоящее время над стандартом на Web-службы для удаленных портлетов работает организация Organization for the Advancement of Structured Information Standards (OASIS).
Web-службы для удаленных порталов
Web-службы для удаленных порталов (Web services for remote portals, WSRP) представляют собой визуальные, настроенные на пользователя компоненты Web-служб, которые подключаются визуально, методом буксировки к порталам или другим промежуточным Web-приложениям, объединяющим информационное наполнение из различных источников. Поставщики информационного наполнения и приложений реализуют свою службу как Web-службу удаленного портала и публикуют ее в общедоступном каталоге (например, в реестре Universal Description, Discovery, and Integration). Этот каталог позволяет владельцам порталов легко находить необходимые службы. Элементы каталога, опубликованные в формате Web Services Description Languag, кратно описывают компонент WSRP и предоставляют детальную информацию о службах. Посредник портлета связывается с компонентом WSRP через SOAP, а протокол удаленного вызова портлета (remote portlet invocation, RPI) гарантирует корректное взаимодействие между обеими сторонами. На рис. 5 показан пример того, как портал находит и интегрирует удаленный портлет.
 |
Рис. 5. Размещение удаленных портлетов. Сервер портлетов находит удаленные портлеты путем поиска в реестре UDDI и вызывает портлеты, которые используют посредников портлетов |
