Файл: Архитектура информационных.pdf

104
Для формирования портлетов могут использоваться либо JSP, либо такие фреймворки, как Java Server Faces (JSF), Struts, Spring [26] и др.
Портлеты могут функционировать в нескольких режимах. Пользователь может работать с информационным наполнением, может настраивать внешний вид портлета в соответствии со своими предпочтениями, а администраторы могут конфигурировать портал для предоставления. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят.
Представление может находиться в одном из следующих состояний: нормальное (normal), максимизированное (maximized), минимизированное
(minimized), закрытое (closed).
Свойства, существенные для размещения портлетов, хранятся в дескрипторе.
Сервер порталов предоставляет портлету сервис получения информационного наполнения и сервис сохранения состояния между том числе предпочтения пользователя, данные о настрой^ ке и т.д.
API портлетов определяет интерфейс между портлетом и контейнером портлетов.
Концепция порталов создавалась постепенно в течение достаточно длительного промежутка времени. Еще за много лет до появления самого терминов «портал» и «портлет» разработчики сайтов широко использовали такие приемы, как введение динамического контента, фреймы, элементы персонализации страницы. Однако различные Web-серверы и серверы приложений обеспечивали эти возможности разными способами. С появлением концепции портала появилась необходимость стандартизации средств построения портальных приложений. В рамках технологии JEE в 2003 г. появилась спецификация JSR-168, которая была разработана совместно фирмами IBM и Sun Microsystems. Она определяла портлеты, написанные на языке Java.
В 2005 году представителем компании IBM был инициирован запрос на спецификацию JSR 286, в котором предлагалось создать новую версию

105 спецификации Java-портлетов для согласования с концепциями J2EE версии
1.4, а также другими JSR (например, c JSR 188) и спецификацией WSRP второй версии.[16]. Предыдущая версия спецификации JSR 168 никак не затрагивала проблемы интеграции, определяя только компонентную модель. Поэтому вопросы интеграции и межпортлетной коммуникации предлагалось специфицировать в новой версии. Работы над второй версией (V2.0) продлились до 12 июня 2008 года, когда её финальный релиз был утверждён экспертной группой, включающей в себя всех значимых разработчиков порталов, как коммерческих, так и с открытым кодом, разработчиков средств интеграции портлетов и разработчиков сред разработки портлетов. Обе версии совместимы на двоичном уровне и это означает, что все портлеты, создание в соответствии со спецификацией JSR-168, могут работать в контейнере, созданном в соответствии со спецификацией JSR-286.
На практике портлеты, созданные в соответствии со специцификацией
JSR-168, продолжают активно использоваться.
Функции для работы с портлетами определены в пакете javax. portlet. API портлетов определены таким образом, чтобы можно было провести четкую границу между портлетом и портальной инфраструктурой.
Хотя API портлетов во многом похожи на API сервлетов, но имеются и отличия, в частности, контейнер портлетов различает и позволяет поддерживать как состояние портлета, так и состояние окна. Состояние окна определяет, какую часть экранной страницы занимает данный портлет. Окно может находиться в одном из трех состояний: нормальном, минимизированном или максимизированном.
В соответствии со спецификацией JSR-168 определяются следующие методы интерфейса Portlet: init(), processAction(), render(), destroy().
Метод init() используется для инициализации портлета.
Метод processAetionO вызывается для обработки действий пользователя в портлете.

106
Метод render() вызывается при необходимости перерисовки изображения портлета.
Метод destroy() вызывается перед удалением портлета из памяти.
Портлет может находиться в одном из трех состояний:
• View (Представление);
• Edit (Редактирование);
• Help (Помощь).
В состоянии
«Представление» портлет реализует свою функциональность, в состоянии «Редактирование» реализуются функции, связанные с настройка портлета, а в состоянии «Помощь» отображаются подсказки.
Наряду с интерфейсом Portlet в пакете определяется класс GenericPortlet, где метод render() определен таким образом, что управление в зависимости от текущего состояния портлета передается одному из методов: doView(), doEdit() или doHelpQ. Большинство реальных портлетов наследуют от класса
GenericPortlet.
Ключевым при работе с портлетом безусловно является метод processAction(), который работает с объектами типа запрос и ответ — объекты
ActionRequest и ActionResponse соответственно. Для метода render() и вызываемых им методов doXxx() в качестве аргументов и результатов выступают объекты RenderRequest и RenderResponse. Используя эти объекты, портлет может управлять состоянием и взаимодействовать с другими портлетами, сервлетами, принимать данные, вводимые пользователем в экранные формы портлета, создавать изображение для отображения в портале и посылать его клиенту и определять состояние портлета.
Запрос клиента инициируется при помощи ссылок URL, создаваемых портлетом. URL портлета могут быть двух типов: URL действия и URL перерисовки. Портлет создает свои URL, вызывая методы createActionURL и createRenderURL интерфейса RenderResponse. Эти методы возвращают интерфейс PortletURL. URL перерисовки может быть уточнен указанием

107 состояния портлета, для которого этот URL применяется. Обычно запрос клиента, инициируемый URL- действия, превращается в один запрос действия и много запросов перерисовки — по одному на каждый портлет на странице портала. Если портлет может кешироваться (это определяется в дескрипторе портлета), метод render может не вызываться.
Портлеты — настраиваемые элементы. Настройки портлета сохраняются в виде наборов пар «имя — значение». За сохранение конфигурации портлета отвечает контейнер. Программист работает с настройками посредством объекта типа PortletPreferences, который имеет методы setValue() и getValue() установки
(изменения) значений настроек и чтения их значений соответственно.
Портлеты упаковываются как стандартные в JEE Web-архивы (файлы
WAR). Кроме дескриптора развертывания web.xml они дополнительно содержат дескриптор портлета — portlet.xml, в котором определены элементы конфигурации портлета.
Основными средствами обеспечения безопасности портлетов в рамках спецификации JSR-168 являются возможность установки в дескрипторе портлета флажка, требующего, чтобы портлет работал только через защищенный протокол HTTPS и возможность аутентификации пользователей и ролей. При этом не определяется, каким образом реализованы пользователи и их роли.
Кроме того, определяется библиотека тегов JSP, помогающая отображать портлет при помощи технологии Java Server Pages. При реализации портлетов довольно часто в методе, например doView(), выполняется логика, связанная с анализом состояния, например некоторая бизнес-логика, а для отображения портлет вызывает страницу JSP, формирующую код фрагмента HTML- страницы.
При вызове страницы JSP ей передаются запрос и отклик портлета. Перед вызовом страницы портлет может сохранить какие-то объекты как атрибуты запроса.

108
Страница может направлять запрос в портлет, определяя адрес портлета через теги специальной библиотеки.
За агрегацию фрагментов, поставляемых разными портлетами в полную страницу портала, отвечает контейнер портлетов.
Стандартизация портлетов (как и само осознание концепции порталов) несколько задержалась. На момент создания спецификации уже существовало большое число реализаций серверов порталов, в которых использовались фирменные средства и собственные API. Спецификация JSR-168, однако, была принята производителями серверов порталов, и в настоящее время большинство продуктов этого класса проходят или уже прошли процесс адаптации к стандарту. Вместе с тем эти продукты вынуждены поддерживать и свои старые API, так что различия в диалектах API быстро исчезнуть не могут.
Следует отметить, что спецификация JSR-168 определяет только базовые средства работы с портлетами. Обычно развитые портальные серверы предлагают многочисленные и не предусмотренные спецификацией дополнительные возможности. При этом у каждого из производителей имеются собственные расширения для работы с портлетами.
В 2007 г. в рамках Java Community Process была опубликована окончательная вторая версия спецификации портлетов (JSR-286), которая дополняет предыдущую спецификацию, обеспечивая стандартизацию возможностей, не охваченных в JSR-168. В качестве новых элементов, появившихся в рамках спецификации JSR-268, можно выделить следующие:
• обеспечение механизмов обмена событиями между портлетами: портлет может объявлять события, которые он хочет генерировать, и события, которые он хочет получать; контейнер работает как диспетчер событий;
• поддержка работы с фильтрами, которая выражается в возможности преообразовывать «на лету» как входную, так и выходную информацию;
• обеспечение возможности для портлетов совместно использовать общий сеанс (сеанс пользователя) и данные, относящиеся к общему сеансу;

109
• обеспечение поддержки работы фреймворками Java AJAX, Server faces,
Struts и др.
Обычно портал получает информационное наполнение для своих портлетов из многих как внутренних, так и внешних источников. Для того чтобы интегрировать новый источник, администратор портала должен адаптировать информационное наполнение к формату, который воспринимается порталом, что может оказаться весьма длительным и трудоемким процессом.
Возможны два альтернативных подхода к решению данной задачи.
Первый подход предполагает, что в каждом случае создается портлет, обеспечивающий пользовательский интерфейс для выполняемой сервисом функции: ввод параметров запроса и представление результатов. На основании полученных данных портлет получает требуемые данные, например из БД, либо формирует SOAP-запрос к сервису и превращает отклик сервиса в графическое экранное представление. Все портлеты работают на одном портальном сервере. Подобный подход требует написания кода портлета, обеспечивающего пользовательский интерфейс, извлечение данных и развертывания портлета. Альтернативный подход заключается в том, что удаленный Web-cepвис сам будет генерировать фрагмент разметки страницы, который непосредственно будет включаться в страницу нашего портала.
Второй подход предполагает использование специальных посредников, использование которых позволяет провайдерам поставлять контент без ручных настроек.
Идея состоит в том, что вместо добавления самого портлета в портальный сервер туда помещают его заместителя, который взаимодействует с удаленным портлетом.
Сам удаленный портлет поддерживается другим сервером порталов или модулем исполнения портлетов. Последний представляет собой упрощенный сервер порталов (среда исполнения портлетов), который дает возможность удаленному портлету реагировать на вызовы посредника. Он может быть

110 реализован в другой технологии,
например .Net, но при этом должен поддерживать протокол удаленного вызова портлета.
Для обеспечения совместимости между портальными серверами разных производителей и поставщиками информационного наполнения требуется стандартизованная модель взаимодействий для посредника портлета и удаленного портлета.
Подобный стандарт создан в рамках организация Organization for the
Advancement of Structured Information Standards (OASIS) — Web-службы для удаленных порталов (Web services for remote portals, WSRP).
Спецификация WSRP является продуктом международной организации
Organization for the Advancement of Structured Information Standards (OASIS).
Организация по развитию стандартизации структурированной информации является консорциумом, содействующим принятию технических стандартов.
Версия 1.0 спецификации WSRP была закончена в 2003 г., а версия 2.0 появилась в 2008 г. [15].
Спецификация WSRP определяет интерфейс для взаимодействия с подключаемыми, ориентированными на представление Web-сервисами, которые обеспечивают взаимодействие с пользователями и выступают в качестве поставщиков фрагментов кода на языке разметки для агрегирования в портальные страницы. WSRP представляют собой визуальные компоненты, которые можно подключать с использованием технологии визуального проектирования. В определенном смысле удаленные портлеты, обладающие графическим интерфейсом, можно рассматривать как Web-сервис, и для их описания может использоваться WSDL.
WSRP работает следующим образом. Поставщики информационного контента реализуют свой сервис как Web-сервис удаленного портала и публикуют ее, например в UDDI.
Можно привести, по крайней мере, два довода в пользу создания отдельного стандарта Web-сервисов для портлетов.

111
Во-первых, обычные Web-сервисы ориентированы на обработку запросов и генерацию откликов, выполняемых преимущественно на программном уровне, в то время как портлеты ориентированы на работу с графическим интерфейсом.
Во вторых, требуется четко определенный интерфейс, определяющий то, как портал взаимодействует с сервисом и собирает фрагменты разметки в портальную страницу. Следует заметить, что удаленные и локальные портлеты могут работать на одном портале и для конечного пользователя они неразличимы.
Работа с удаленным портлетом выглядит следующим образом.
Поставщик предлагает один или несколько портлетов и реализует ряд интерфейсов WSRP, обеспечивающих общий набор операций для конечных пользователей. WSRP-портлет представляет собой подключаемый компонент, формирующий интерфейс конечного пользователя. Он выполняется внутри поставщика WSRP и доступен удаленно через интерфейс, определенный этим поставщиком.
Потребитель WSRP представляет собой клиента Web-сервиса, который вызывает WSRP-сервис и обеспечивает среду взаимодействия пользователя с портлетами, предлагаемыми одним или несколькими поставщиками; обычно роль потребителя WSRP играет портал.
Реально Web-сервисом является не WSRP-портлет, а поставщик WSRP, именно он имеет стандартное описание на языке WSDL и набор конечных точек. Обращение к WSRP-портлету возможно только через поставщика.
Поставщик принимает SOAP-запрос, выделяет из него обращение к портлету и упаковывает фрагмент разметки, генерируемый портлетом, в ответное SOAP- сообщение. В функции же потребителя WSRP входит упаковка в SOAP-запрос параметров формы, поступившей от пользователя, и выделение из SOAP- отклика фрагмента разметки, присланного поставщиком и WSRP-портлетом.
В рамках спецификации WSRP определены два обязательных и два необязательных интерфейса, которые должны реализовывать поставщики

112
WSRP и использовать потребители WSRP для взаимодействия с удаленными портлетами. Стандартизация этих интерфейсов дает возможность потребителю
WSRP обращаться к любому поставщику.
Обязательными для реализации интерфейсами WSRP являются интерфейс описания сервиса (Service Description Interface) и интерфейс разметки (Markup Interface).
Через Интерфейс описания сервиса потребители могут запрашивать, какие портлеты предлагает поставщик, и получать информацию о самом поставщике.
Интерфейс разметки предназначен для поддержки взаимодействия поставщика с удаленными портлетами. Он позволяет посылать им формы от пользователя портальной страницы и получать от них информацию о текущем состоянии портлета.
Необязательными интерфейсами WSRP являются интерфейс регистрации
(Registration Interface) и интерфейс управления портлетом (Portlet Management
Interface).
Интерфейс регистрации предназначен для поддержки процесса регистрации потребителя перед тем, как тот сможет обратиться к сервису. Это позволяет поставщику сервиса адаптировать свое поведение применительно к определенному типу потребителя; через этот интерфейс поставщик и потребитель могут обмениваясь сведениями о себе.
Интерфейс управления портлетом позволяет пользователю управлять жизненным циклом удаленного портлета и настроить его поведение.
Все перечисленные выше интерфейсы WSRP представляют собой XML- протоколы и соответственно платформенно независимы.
Следует особо отметить, что WSRP не заменяет стандарты Web- сервисов, а дополняет их и предствляет собой надстройку над ними.
Все взаимодействия между потребителем и поставщиком WSRP осуществляются по протоколу SOAP, а операции интерфейсов WSRP определяются в WSDL-описании WSRP. Использование подобного подхода

113 позволяет осуществлять публикацию WSDL-описаний WSRP-портлетов в реестрах UDDI.
Типовой сценарий использования WSRP на основе технологии UDDI выглядит следующим образом.
1.
Провайдер разрабатывает набор портлетов, назначая WSRP- поставщика и отображая их как WSRP-портлеты. Если провайдер хочет, чтобы эти портлеты использовались как удаленные, то он публикует их описания в реестре.
2.
Пользователь, заинтересованный в работе с удаленными портлетами, ищет нужный ему портлет, используемые предоставляемые порталом средства, либо независимое приложение.
3.
После обнаружения желаемого портлета пользователь добавляет новое приложение к одной из своих портальных страниц.
4.
Если пользователю не разрешено добавление портлетов к своей странице, то администратор портала находит их в UDDI-реестре и сделает их доступными для пользователей, добавив во внутренний реестр портала.
5.
После того как удаленный портлет помещен на портальную страницу пользователя, он увидит на своей портальной странице выполняющийся удаленно портлет, при обращении к которому портальный сервер выполняет запрос к соответствующему Web- сервису посредством отправки SOAP-послания, а в ответ получает SQAP-послание с фрагментом на языке разметки страниц, который портал интегрирует в отображаемую страницу. При этом конечный пользователь полностью избавлен от необходимости знать детали работы WSRR
Как у всякой технологии, у технологии портлетов имеются свои области применения достоинства и недостатки.
Использование портлетов безусловно целесообразно в случае, если цель проекта состоит в том, чтобы объединить Web-приложения и информацию в одном удобном месте, если требуется использовать сервисы внешних поставщиков и (или) выступать в качестве поставщика сервиса. Если