Технология сервера порталов

2003 г

Технология сервера порталов

Кристиан Веже
19.09.2002
Открытые системы, #09/2002

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

Порталы, в основном, базируются на существующей технологии Web-приложений, такой как Web-серверы и Java 2 Platform Enterprise Edition (J2EE). В статье предлагается обзор типов порталов и их служб, а также более детальный анализ архитектур и компонентов, предназначенных для построения порталов.

Рис. 1. Страница с портала Yahoo. На ней содержится информация, ориентированная на конкретного пользователя и сформированная с помощью специальных компонентов настройки

Службы и использование порталов

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

Общедоступные порталы, такие как Yahoo, открыты для всех и объединяют информацию из различных источников и приложений и поступающую от разных людей, предлагая персонифицированные Web-сайты для произвольных категорий посетителей.
Порталы предприятий (или "корпоративные рабочие пространства") предоставляют сотрудникам доступ к характерным приложениям и информации, используемым внутри организации.
Торговые порталы, такие как eBay и ChemWeb, - это торговые площадки, которые связывают продавцов и покупателей.
Специализированные порталы, такие как портал MySAP.com, предлагают путь доступа к приложениям определенного вида.

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

Служба настройки (customization) распознает различных пользователей и предлагает им информационное наполнение, сконфигурированное с учетом их специфических требований. Эта служба основана на сборе информации о пользователях и сообществах пользователей и должна предоставлять нужное информационное наполнение в нужное время.
Служба агрегирования информационного наполнения (content aggregation) готовит информацию, полученную из различных источников для различных пользователей. Она учитывает ориентированный на конкретного человека контекст, идентифицируя пользователя с помощью службы защиты и службы настройки.
Служба получения информационного наполнения (content syndication) накапливает информацию из различных источников. Поставщики коммерческого информационного наполнения часто предоставляют информацию в стандартизованных форматах, таких как RSS (rich site summary, "расширенное резюме сайта"), NITF (news industry text format, "текстовый формат индустрии новостей") и NewsML, стандарт на базе языка XML, используемый для представления и управления новостями на протяжении всего их жизненного цикла. Самая распространенная операция - "клиппировать" (вырезать) информацию с существующих Web-сайтов, скопировав ее в формате HTML на портал. Портал для сотрудников, к примеру, может вырезать ее из внутрикорпоративной интранет-сети.
Служба поддержки устройств (multidevice support) готовит информационное наполнение для различных каналов коммуникаций (например, проводные и беспроводные телефоны, пейджеры и факсы), анализируя их характеристические особенности. Как правило, для этого необходимо фильтровать информационное наполнение (скажем, из информации, предназначенной для беспроводного телефона, при этом удаляют все изображения, а для беспроводных соединений WML - преобразуют HTML в язык разметки).
Служба единой регистрации (single sign-on) позволяет службе получения информационного наполнения обращаться к внутрикорпоративным системам и извлекать информацию, ориентированную на конкретного пользователя, не требуя, чтобы пользователь каждый раз подтверждал свою личность. Число систем, которые требуют аутентификации и должны быть доступны через портал, быстро растет. Один из примеров - корпоративные приложения управления кадрами.
Администрирование портала (portal administration) определяет, как пользователи видят портал. Это не только внешний вид; также в зависимости от природы портала должны задаваться группы пользователей, каналы коммуникаций и информация о правах доступа.
Управление пользователями портала (portal user management) меняется в зависимости от аудитории портала. Пользователи, как правило, могут подписываться на общедоступные Web-порталы, но не на корпоративные порталы. Кроме того, в зависимости от типа портала число пользователей может варьироваться от десятков до десятков тысяч и миллионов. В некоторых случаях администраторам приходится распределять пользователей портала по группам таким образом, чтобы портал мог предоставлять информационное наполнение с учетом роли пользователя, его интересов, местонахождения, функций или служебного положения.

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

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

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

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

В данной статье речь о портлетах и контейнерах портлетов ведется в терминах 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 и вызывает портлеты, которые используют посредников портлетов

Выводы

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

Большинство современных серверов порталов базируются на Java. Компании Epicentric и Plumtree, пожалуй, первыми предложили серверы порталов как отдельные продукты. С приобретением компании TopTier корпорация SAP смогла присоединиться к ним имеющемуся в ее системе уровню интеграции приложений iViews. Корпорация IBM предлагает WebSphere Portal Server, который базируется на технологиях свободно распространяемой портальной платформы Jetspeed, реализованной в рамках проекта Apache. Со своей стороны, Apache принимает участие в разработке спецификаций для API портлетов в стандарте J2EE, благодаря чему Jetspeed стал серьезным кандидатом на роль эталонной реализации нового стандарта. Еще одна свободно распространяемая портальная платформа Zope реализована компанией Python. Помимо функций портала Zope предлагает некоторые возможности управления информационным наполнением и общие службы Web-приложений. (Этот список, конечно, не полон.)

В ближайшем будущем мы станем свидетелями стабилизации и более надежной интероперабельности между серверами порталов различных производителей по мере того, как они будут реализовывать ориентированные на порталы стандарты. Включение в состав спецификации J2EE интерфейса API портлетов также будет способствовать значительному расширению использования технологии портальных серверов, учитывая известность спецификации J2EE.Что касается других элементов спецификации J2EE, популярность свободно распространяемых реализаций будет расти, вынуждая к тому производителей, стремящихся сохранить свои конкурентные преимущества. В ближайшем будущем скорость внедрения технологии будет определять жизнеспособность рынка служб портлетов. Наконец, в перспективе, технология серверов порталов может распространяться на новые области. Представьте, к примеру, принтер, который предлагает свой пользовательский интерфейс управления как Web-службу удаленного портлета в рамках портала системного управления, обратиться к которому можно по телефону.

Крстиан Веже (wege@acm.org) — аспирант университета Тюбингена (Германия) и разработчик приложений корпорации DaimlerChrysler. К области его научных интересов относятся архитектура программного обеспечения и взаимозависимость между эволюцией программного обеспечения и эволюцией методологии.

Попытки стандартизации серверов порталов

Попытки стандартизации предпринимаются в двух важных областях: API-интерфейсы портлетов и Web-службы для удаленных порталов.

API-интерфейсы портлетов

Эксперты Java Community Process работают над расширением стандарта J2EE с целью унифицировать свободно распространяемое программное обеспечение и коммерческие продукты различных производителей. Помимо унификации необходимо гарантировать, что API-интерфейсы портлетов будут основаны на открытых стандартах.

Эта спецификация будет состоять из самих портлетов, API-интерфейсов портлетов и формата дескриптора развертывания. Сегодня, однако, не существует открытой для публики предварительной спецификации; нет эталонной реализации.

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

Web-службы для удаленных порталов

Технический комитет организации Organization for the Advancement of Structured Information Standards сейчас разрабатывает стандарт на Web-службы для удаленных порталов. Данный стандарт, WSRP, позволит организовать взаимодействие ориентированных на пользователей Web-служб с порталами и другими Web-приложениями промежуточного слоя. Это также даст возможность реализовывать удаленные портлеты на любой платформе, будь то J2EE, .NET или некоторая служба, поддерживающая SOAP.