Создание сайтов - статьи

Архитектура и компоненты портала


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

Портлеты и контейнеры портлетов

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

В данной статье речь о портлетах и контейнерах портлетов ведется в терминах J2EE, поскольку данная платформа поддерживает и структуру портлетов, и взаимодействие портлетов со средой времени исполнения. Кроме того, большинство реализаций серверов порталов — это Web-приложения на базе J2EE.

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

Точно так же портлеты размещаются в контейнерах портлетов. API портлетов определяет интерфейс между портлетом и контейнером портлетов.

Рис. 2. Простой портлет. Здесь приведена реализация портлета, подготовленная для среды Apache Jetspeed

На рис. 2 показана простая реализация портлета. Как и сервлет, портлет существует в единственном экземпляре, который создается один раз в контейнере портлетов, а затем может многократно использоваться в различных нитях управления. В состав API портлетов входят следующие элементы:

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




    Портлеты существуют в нескольких режимах. Пользователи могут видеть представленное информационное наполнение, запускать службу помощи для конкретного представления или редактировать представление таким образом, чтобы настроить его в соответствии со своими предпочтениями, а администраторы могут конфигурировать портал для предоставления настроенных служб. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Кроме того, представление может находиться в одном из нескольких состояний, в том числе normal («нормальное»), maximized («максимизированное»), minimized («минимизированное»), closed («закрытое») и т.д. Как и дескрипторы размещения сервлетов, дескрипторы портлетов содержат свойства, существенные для размещения конкретного портлета.

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





    Рис. 3. Строительные блоки сервера порталов.
    На рис. 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 и вызывает портлеты, которые используют посредников портлетов

    Содержание раздела