Технология Клиент-Сервер 2002'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Создание корпоративных информационных порталов на основе технологии портлетов. Сравнение подходов Microsoft Digital Dashboard и портлетов J2EE.

В этой статье рассказывается о том, как создавать корпоративные информационные порталы на основе технологии портлетов – стандартных портальных компонентов. Сейчас в этом направлении работают многие компании, но пионерами в данной области являются старые конкуренты – Microsoft и Sun. Microsoft продвигает свою технологию Digital Dashboard, которая уже довольно широко распространена. Sun объединила вокруг себя целую группу компаний (IBM, BEA, iPlanet, Oracle, SAP, Epicentric и Apache Software Foundation), и теперь они вместе разрабатывают собственную технологию портлетов на основе Java. Цель этой статьи – представить эти подходы к разработке корпоративных порталов, и, возможно, помочь вам выбрать лучший.

Введение

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

• обеспечения доступа к широкому кругу источников информации (персональных, групповых, корпоративных и внешних),

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

Давайте запомним эти задачи, так как мы еще не раз будем возвращаться к ним. Концепция корпоративного портала – последняя, и пока наиболее удачная попытка решить данные проблемы. С точки зрения пользователя, корпоративный информационный портал (в английском языке существует устоявшаяся аббревиатура – Enterprise Information Portal или, сокращенно, EIP), – это способ собрать на одном экране всю необходимую ему для работы информацию. При создании порталов используется архитектурный шаблон на основе “толстого” Web-клиента, таким образом, для доступа к информации и поставляющим ее системам (финансовым, почтовым и другим) достаточно привычного Internet-браузера, поддерживающего апплеты Java и компоненты ActiveX. Корпоративный портал хранит информацию о структуре и сотрудниках организации, и выполняет за них авторизацию к другим доступным информационным системам. Портал позволяет добавлять и удалять компоненты, представляющих разные категории ресурсов (структурированная и неструктурированная информация, внешние и внутренние источники, почта и офисные документы) и предоставляет средства их анализа.

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

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

Стандартный портальный компонент (портлет) в данном случае определяется как реализация некоторого сервиса, запускаемая портальным сервером, которая содержит некоторые данные, набор собственных бизнес функций, а также стандартное представление на рабочих панелях портала. Портлеты обычно (но не обязательно) выглядят как стандартные "окошки" на рабочей панели. Их можно открывать и закрывать, удалять и перемещать с места на место, что позволяет объединять на одном экране разнородную информацию, полученную из различных источников: персонального компьютера, локальной или корпоративной сети предприятия, и даже Internet. Перечень операций пользователя с портлетом определяется его ролью и установками, заданными администратором.

Гипертекстовые документы практически идеально подходят для представления портлетов, сочетая низкую стоимость разработки с практически неограниченными возможностями. Поэтому сегодня наметилась тенденция создавать корпоративные информационные порталы в виде “многооконного” web-приложения в окне браузера. Таким образом, можно провести следующую аналогию между операционными системами и Web-приложениями.

В старых реализациях компонентных порталов портлеты ассоциировались с их программной реализацией, например в форме JSP или ASP. Современная тенденция сводится к тому, чтобы зафиксировать поведение и содержание сервиса портлета в виде стандартного XML-описания, сохранив возможности альтернативных реализаций. Такие портлеты могут запускаться разными портальными серверами и показываться на различных устройствах. Итак, можно дать новое определение портлета. Портлет – это многократно используемый компонент, который содержит в себе некоторые данные, набор собственных бизнес функций и стандартную схему свойств (property schema), определяющую содержание сервиса портлета, в том числе и то, каким образом этот портлет отображается в браузере пользователя.

Поскольку в будущем портлеты будут строиться на основе единого стандарта (прежде всего – это стандартное XML-описание), компании смогут создавать библиотеки этих компонентов для построения корпоративных информационных порталов, а системные администраторы смогут распространять компоненты, используя эти библиотеки.

В этой статье мы рассмотрим две наиболее перспективные технологии создания корпоративных информационных порталов на основе портлетов. Это Digital Dashboard от Microsoft и J2EE-портлеты от группы компаний, куда входят Apache Software Foundation, BEA, IBM, iPlanet, Oracle, Epicentric.

Обе эти технологии описывают создание стандартных портальных компонентов. В каждом случае мы рассмотрим архитектуру соответствующих технологий, а также подробно рассмотрим процесс создания портлета. Портлет может содержать встроенный контент, который, в свою очередь, может быть представлен в самых разнообразных форматах, или ссылки на контент, находящийся на удаленном сервере. Тип разрабатываемого портлета зависит от его назначения, местоположения и объема информации, которую он должен отображать. Например, если вы создаете портлет со статическим контентом, этот контент можно встроить непосредственно в портлет. Если же вы разрабатываете компонент, который получает контент из другого источника, например, базы данных, корпоративного web-узла или из Internet, можно использовать в этом компоненте ссылку, указывающую на источник данных.

Обе технологии портлетов, которые мы рассмотрим, поддерживают различные типы контента и для каждой технологии портлетов мы рассмотрим наиболее важные типы контента. Также мы рассмотрим свойства схемы (schema properties) портлета. Они определяют, как выглядит портлет, место, откуда он получает контент, как он выполняется, каким образом пользователь может изменять его свойства и так далее. Сначала мы рассмотрим технологию Digital Dashboard от Microsoft, которая была создана двумя годами раньше, и на сегодня уже широко распространена, а уже затем технологию J2EE-портлетов и ее реализацию в свободно распространяемом сервере портлетов Apache Jetspeed. В последнем разделе мы обсудим общие требования к портлетам и попытаемся сравнить их решения в каждой из упомянутых технологий.

Microsoft Digital Dashboard

Технология Digital Dashboard (DDB) была впервые представлена публике в конце лета 1999 года, тогда же появился специальный набор для разработчиков DDB Startup Kit. Пользователи и разработчики довольно быстро оценили новинку – к моменту появления нового набора ресурсов DDB Resource Kit 2.01 летом 2000 года, по данным Microsoft, было загружено более 300 тысяч комплектов инструментария для создания DDB, а число реализованных проектов исчислялось сотнями. В первый год существования DDB российское отделение Microsoft не проявляло заметной активности в продвижении данной технологии, однако с осени 2000 года DDB была уже представлена как одно из главных направлений работы корпорации в нашей стране. А в октябре был открыт русскоязычный сервер по этой тематике (http://www.myddb.ru/).

Digital Dashboard (DDB) или "электронная информационная панель" позволяет создавать настраиваемые решения для сотрудников, работающих с информацией. Основной составляющей электронной информационной панели, как вы уже наверно догадались, являются портлеты, в терминологии Microsoft называемые Web Part или DDB-компоненты. Таким образом, информационная панель Digital Dashboard может объединять персональную, групповую, корпоративную и внешнюю информацию, предоставляя доступ к различным инструментам анализа и источникам информации.

На рисунке 1 представлена архитектура Digital Dashboard. Верхний уровень представляет собой отображение набора DDB-компонентов (Web Part) на HTML-странице. Сюда же входит компонент Digital Dashboard Services Component – это клиентский компонент, который включается в состав каждой электронной информационной панели как скрытый объект. Он предоставляет пользовательским DDB-компонентам следующие службы:

Средний уровень содержит модуль хранения и DDB-механизм, который работает под управлением Microsoft Internet Information Services (IIS). Dashboard factory (DDB-механизм), кодовый механизм (ASP), который "собирает" DDB-компоненты в визуальное представление, необходимое для отображения на электронной информационной панели. Уровень данных содержит хранилище DDB-компонентов, в качестве которого может использоваться Microsoft SQL Server, файловая система NTFS или Microsoft Exchange 2000 Server. Работать с хранилищем компонентов можно по протоколу WebDAV (Web Distributed Authoring and Versioning), который представляет собой набор расширений протокола HTTP/1.1, обеспечивающих публикацию, совместное редактирование и управления файлами на удаленных Web-серверах.

Перед тем как приступить к созданию своего первого DDB-компонента, нужно установить пример электронной информационной панели (работающей, например, с файловой системой) на компьютер с Windows 2000 Server, Internet Information Services (IIS) 5.0 и файловой системой NTFS. Для установки примера выберите пункт Install the File System Sample Digital Dashboard на странице "Building Digital Dashboards" комплекта Digital Dashboard Resource Kit, который вы можете скачать по адресу http://msdn.microsoft.com/msdn-files/027/001/584/DDRKWeb.exe. Можно также просто запустить на установку файл DDRK_FS.msi. Программа-мастер установки проведет вас через все шаги установочного процесса.

DDB-компоненты можно создавать двумя различными способами – непосредственно в самой электронной панели или с помощью дополнения Web Part Builder. Процесс создания компонента с помощью электронной панели довольно прост. Даже не очень подготовленный пользователь может создать простой DDB, который, например, отображает некоторый web-узел. DDB-компонент может содержать встроенный контент, который, в свою очередь, содержит HTML- или XML-код, сценарии, элементы управления ActiveX или ссылки на любой Web-контент, находящийся в любом месте. Ниже мы рассмотрим отдельно эти два случая.

Комплект Digital Dashboard Resource Kit определяет XML-схему для DDB-компонентов, которую интерпретирует DDB-механизм. Свойства схемы (schema properties) определяют, как выглядит DDB-компонент, место, откуда он получает контент, как он выполняется, каким образом пользователь может изменять его свойства и так далее. Свойства схемы разделяются на несколько классов. Базовые свойства (Basic Properties) определяют базовые метаданные DDB-компонента. Сюда входят описание DDB-компонента, дата и время модификации DDB-компонента, заголовок DDB-компонента и пространство имен для DDB-компонента. Свойства вида (Appearance Properties) определяют, как именно DDB-компонент отображается на электронной информационной панели. Например, свойствами вида являются высота и ширина DDB-компонента на панели, ссылка (URL) на страницу DDB-компонента, которая чаще всего используется для его настройки, и еще несколько подобных свойств. Свойства контента (Content Properties) определяют, откуда DDB-компонент получает свой контент, какую часть веб-страницы он отображает и тип контента. К ним относятся встроенный контент и тип встроенного контента (HTML, VBScript, JavaScript, XML) или ссылка (URL) для использования вместо встроенного контента. Свойства выполнения (Execution Properties) говорят о том, как DDB-компонент выполняется на электронной информационной панели. Они определяют, когда и как DDB-механизм кэширует контент, нужно ли изолировать DDB-компонент от других компонентов и так далее. При разработке DDB-компонента используются только действительно нужные свойства схемы компонента. Все остальные свойства при этом будут иметь значения, используемые по умолчанию.

Создание DDB-компонентов
со встроенным контентом

Для создания DDB-компонента со встроенным контентом (embedded content) следует использовать свойство Content в схеме DDB-компонента. Весь контент, который отображается компонентом, содержится в этом свойстве – это может быть HTML-или XML-код, а также сценарий на языке VBScript или JavaScript. Ниже приводится код для DDB-компонента, который отображает этот абзац.

<?xml version="1.0"?>
<WebPart>
<Title>WebPart with embedded content made by Peter Miheev</Title>
<Description>WebPart with embedded content made by Peter Miheev </Description>
<Content>
<![CDATA[
Вставьте сюда свои данные! 
]]>
</Content>
<ContentType>0</ContentType>
<IsVisible>1</IsVisible>
<AllowRemove>1</AllowRemove>
</WebPart>

Пример DDB-компонента, содержащего встроенный контент

На приведенном рисунке показано, как будет выглядеть этот DDB-компонент на электронной информационной панели.Если DDB-компонент будет содержать не HTML-контент, в дополнение к свойству Content нужно использовать и свойство ContentType – это позволит DDB-механизму правильно интерпретировать содержание DDB-компонента. В таблице 1 приведены возможные значения свойства ContentType.

Типы контента

Если значение свойства ContentType не равно ни одному из приведенных в таблице, то DDB-механизм интерпретирует его как unknown. Однако, при создании специализированного DDB-компонента, можно модифицировать DDB-механизм, чтобы расширить список возможных значений этого свойства. Если вы не задали значение этого свойства, то будет использоваться значение по умолчанию – 0 или – HTML.

При создании DDB-компонента со ссылками на контент (linked content) для указания ссылки на источник контента используется свойство ContentLink. Контента может быть HTML-кодом (значение по умолчанию), VBScript- или JavaScript-сценарием, а также XML-кодом. Чтобы DDB-механизм мог правильно интерпретировать этот контент, следует использовать свойство ContentType.

Ниже приведен пример DDB-компонента, содержащего ссылку на главную страницу Digital Dashboard Resource Kit, находящийся на узле localhost. Электронную информационную панель с этим компонентом можно увидеть на рисунке 3, который был приведен выше (это компонент находится в правой части страницы).

<WebPart>
<Title>WebPart with linked content made by Peter Miheev</Title>
<Description>A Web Part that contains linked content</Description>
<ContentType>0</ContentType>
<ContentLink>http://localhost</ContentLink>
<RequiresIsolation>1</RequiresIsolation>
</WebPart>

Пример DDB-компонента,
содержащего ссылку на контент

По умолчанию, контент, на который указывает ссылка, читается непосредственно в страницу компонента и включается в объектную модель документа электронной панели. Однако, вы можете захотеть, чтобы DDB-компонент просто отображал окно с той web-страницей, на которую вы задали ссылку. В этом случае вы должны установить значение свойства RequiresIsolation равным TRUE, чтобы поместить DDB-компонент в IFrame. На рисунке, приведенном выше, показано, что в правой части электронной информационной панели страница отображается в отдельном фрейме.

Создание DDB-компонента с XML-контентом

Чтобы создать DDB-компонент с XML-контентом, нужно использовать одну из четырех комбинаций свойств, приведенных в таблице 2.

Варианты создания DDB-компонентов с
XML-контентом

При создании DDB-компонентов со встроенным XML-контентом или со ссылкой на него, вы должны установить значение свойства ContentType равное 3 – XML. Это нужно для того, чтобы DDB-механизм распознал содержание свойств Content или ContentLink как XML–код и правильно интерпретировал его.

Ниже приведен пример DDB-компонента, который содержит ссылку на XML-контент и ссылку на XSL-файл, который будет использоваться DDB-механизмом для преобразования XML:

<WebPart>
<Title> WebPart with linked content made by Peter Miheev </Title>
<Description>A Web Part that contains embedded XML and a link to a site containing XSL.</Description>
<ContentType>3</ContentType>
<ContentLink>http://localhost/message.xml</ContentLink</ContentLink>
<XSLLink>http://localhost/presentmsg.xsl</XSLLink>
</WebPart>

Пример DDB-компонента,
содержащего XML-контент

Ниже приводятся собственно сам XML-документ и XSL-преобразование.

<?xml version="1.0" encoding="windows-1251"?>
<msg>Hello World form Peter Miheev!</msg>

XML-контент

<?xml version="1.0" encoding="windows-1251"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<h2> Message is <xsl:apply-templates select="msg"/> </h2>
</xsl:template>
<xsl:template match="msg">
<b> <xsl:value-of select="."/> </b>
</xsl:template>
</xsl:stylesheet>

XSL-преобразование

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

J2EE-портлеты

J2EE — одна из самых известных серверных компонентных моделей. В J2EE серверные компоненты размещаются в специальных контейнерах. Контейнер представляет собой среду выполнения для серверного компонента, он вызывает компонент и предоставляет специфические для компонента службы (например, информацию о пользователе и сохранение состояния объекта между сеансами). Портлеты также размещаются в контейнерах портлетов. Сегодня этот процесс регулируется предварительными версиями двух стандартов. Это JSR 168 Portlet Specification и JSR 162 Portlet API. Предварительные версии этих спецификаций закрыты для публики. Следовательно, остается полагаться лишь на публикации в Internet и на реализации серверов порталов компаний, которые принимают участие в разработке спецификаций.

Portlet Specification определяет портлет как отдельный программный модуль (класс Java), который выполняется внутри контейнера портлетов (портального сервера), и стандартную схему свойств (property schema), которая определяет процесс развертывания портлета, а также каким образом этот компонент отображается в браузере пользователя. Таким образом, портлеты очень похожи на сервлеты, которые выполняются внутри контейнера сервлетов (например, Apache Tomcat или Resin) и имеют XML-описание свойств приложения (файл web.xml).

На рисунке 4 показаны типичные строительные блоки портального сервера, созданного как приложение на базе Java-сервлетов. Ядро портального сервера получает запрос от контейнера сервлетов и преобразует этот запрос в специфический запрос, который оно и направляет соответствующему портлету. Портлет должен извлечь свое информационное наполнение, используя службы, предоставленные сервером порталов. Затем ядро портала объединяет множество ответов отдельных портлетов в одну страницу и возвращает ответ пользователю. Чтобы корректным образом вывести страницу, служба агрегирования учитывает предпочтения пользователей и возможности устройства.

Интерфейс между контейнером портлетов и портлетами определен в Portlet API. Если вы работали с сервлетами и с Servlet API, то обнаружите, что Portlet API концептуально подобен Servlet API. В состав API портлетов входят следующие элементы:

Объекты, инкапсулирующие HTTP-запрос и HTTP-ответ в рамках портлета. Например, HTTP-запрос (PortletRequest) содержит дополнительные параметры, специфические для портлетов (например, состояние (maximized, minimazed, normal) и режим (view, help, edit, configure) портлета, а также MIME-тип программы просмотра). В HTTP-ответ (PortletResponse) Вы также можете добавлять дополнительные параметры. Например, в состав Portlet API входят классы, которые позволяют включать в содержимое портлета ссылку на самого себя.

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

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

2. После входа пользователя в портал каждый portlet создает сеанс для пользователя. Комбинация физического образа портлета и пользовательского сеанса создает виртуальный образ портлета. Для создания виртуального образа портлета портальный сервер вызывает метод login(). Этот метод позволяет портлету инициализировать сеанс пользователя, например, сохранить в сеансе необходимые атрибуты.

3. Затем контейнер портлетов вызывает метод service()/getContent() портлета (в серверах различных производителей методы названы по-разному, причина – отсутствие спецификаций), который собственно и выводит содержимое портлета на экран. В течение жизненного цикла портлета метод service()/getContent() обычно вызывается много раз.

4. Когда пользователь выходит из портала, вызывается метод logout() портлета.

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

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

Сегодня создание спецификаций портлетов не завершено, и каждый производитель (Apache Software Foundation (Jakarta JetSpeed), BEA (Web Logic Portal), IBM (WebSphere Portal), iPlanet (iPlanet Portal Server), Oracle (Oracle 9i Portal), SAP (Portal Server), Epicentric (Portal Server)) реализуют собственный набор функций и классов. Например, функция получения содержимого в Apache Jetspeed называется getContent(), а в IBM WebSphere Portal – Service(). Поэтому сегодня нужно быть предельно осторожным в реализации приложений на базе J2EE-портлетов, поскольку завтра, когда спецификации будут окончательно сформированы, в код портлетов придется вносить изменения.

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

Jetspeed – это открытый проект от Apache Software Foundation, который позволяет разработчикам создавать корпоративные порталы. Архитектура Jetspeed представлена на рисунке 3.

Написанный на языке Java, Jetspeed содержит Portlet API, а также Apache Turbine (http://jakarta.apache.org/turbine) – часть Java Apache Project. Turbine – это полноценная, основанная на MVC система для построения Web-приложений. Часть функциональных возможностей Turbine пересекается с сервисами, которые обеспечиваются серверами приложений J2EE. Поскольку Jetspeed написан на языке Java, и использует технологию сервлетов, для работы с ним потребуется установить контейнер сервлетов. Самым подходящим из них, на мой взгляд, является Apache Tomcat, который можно загрузить c http://jakarta.apache.org/tomcat. При работе с Apache Tomcat не нужно устанавливать HTTP-сервер. Чтобы установить Jetspeed, нужно просто распаковать его дистрибутив (который можно загрузить с http://jakarta.apache. org/jetspeed) в папку приложений для Tomcat /webapps.

Рисунок 3. Архитектура Apache Jetspeed.

Реализация собственного портлета

Тип портлета в Jetspeed по существу один, – это класс Java. Поэтому мы не будем рассматривать различные типы портлетов, как было сделано для Microsoft DDB, а просто посмотрим, как правильно реализовать некоторый эталонный портлет.

Для реализации собственного портлета в Jetspeed нужно создать Java-класс, который реализует интерфейс org.apache.jetspeed.portal.Portlet, или же можно создать свой портлет путем наследования от класса, который реализует этот интерфейс, например, класса AbstractPortlet. AbstractPortlet – это абстрактный базовый класс для всех портлетов. Вы не можете создавать экземпляры этого класса, он используется только для создания других портлетов. Следуя традиции, напишем самый простой портлет “Hello World!”. Код этого портлета приводится ниже:

package org.ras.portal.portlets;

import org.apache.jetspeed.portal.portlets.AbstractPortlet;
import org.apache.turbine.util.RunData;
import org.apache.ecs.ConcreteElement;
import org.apache.ecs.StringElement;
 
public class HelloWorldPortlet extends AbstractPortlet
{
  public ConcreteElement getContent (RunData runData)
  {
    return (new StringElement ("Hello World!"));
  }
}

Пример J2EE-портлета “Hello World!”

Как видеть, в портлете есть только один метод getContent(). GetContent() использует объект RunData, который входит в состав Turbine. В объекте RunData содержится вся информация, необходимая для правильной работы портлета. Чтобы Jetspeed узнал о портлете, нужно сделать две следующие вещи:

• Поместить класс, представляющий портлет, в classpath.

• Добавить ссылку на портлет в системный реестр Jetspeed.

Чтобы добавить в реестр ссылку на портлет, нужно создать файл системного реестра в каталоге /WEB-INF/conf. Файлы Системного реестра содержат определения портлетов. Любой файл в каталоге /WEB-INF/conf, который имеет расширение xreg, включается в системный реестр Jetspeed. Для нашего примера запись в системном реестре будет такой:

<?xml version="1.0" encoding="UTF-8"?>
<registry>
  <portlet-entry name="HelloWorld" hidden="false" type="instance" 
     application="false">
    <meta-info>
      <title>HelloWorld</title>
      <description>Simple Portlet Example </description>
    </meta-info>
<classname>
  org.ras.portal.portlets.HelloWorldPortlet
</classname>
    <media-type ref="html"/>
  </portlet-entry>
</registry>

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

Портлет не обязательно должен представлять класс Java. Можно создавать свои портлеты на любом языке серверных сценариев. Для этого нужно написать написать собственный портлет (такой портлет называется wrapper – “обертка”), который вызывает интерпретатор соответствующего языка и передает ему в качестве параметра скрипт, выводящий содержимое портлета. Jetspeed содержит 7 таких “оберток” для создания следующих типов портлетов:

• HTML portlet - поддерживает тип данных HTML.

• JSP portlet – использует JSP шаблон, чтобы получить содержимое портлета.

• RSS portlet – использует новости в формате RSS (RDF Site Summary) от локального или отдаленного источника.

• WebPage portlet – включает содержание из другого web-сайта в портлет, изменяя относительные ссылки на абсолютные к первоначальному сайту.

• XSL portlet – производит XSLT-преобразование.

• Velocity portlet – использует шаблон Velocity, чтобы получить содержимое портлета. Velocity – это простой язык создания сценариев (с синтаксисом, похожим на PHP). Некоторые разработчики утверждают, что скрипты Velocity проще изучать и отлаживать чем страницы JSP. Полную информацию о Velocity можно посмотреть по адресу http://jakarta.apache. org/velocity.

• WML Portlet - поддерживает тип данных WML.

Рисунок 4. Пользователь может выбрать портлет “Hello World!” из списка портлетов.

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

Общие требования к построению портлетов

Чтобы выделить характерные требования к построению портлетов, давайте вернемся к задачам, которые решаются при помощи порталов:

• обеспечение доступа к широкому кругу источников информации (персональных, групповых, корпоративных и внешних);

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

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

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

• Функции в разных компонентах имеют одинаковые имена.

• Объекты в разных компонентах имеют одинаковые имена.

• Переменные в разных компонентах имеют одинаковые имена.

Чтобы полностью изолировать портальный компонент от других компонентов, можно размещать этот компонент в IFrame. И Digital Dashboard, и Jetspeed позволяют это делать. Запрос контента для изолированного компонента происходит асинхронно от остальных компонентов, расположенных на этой же странице, поэтому такая изоляция может быть удобной и в случае, когда связанный контент медленно загружается. Отрицательной стороной является то, что, например, в DDB становится недоступными служебные компоненты.

Если вы не хотите изолировать портальный компонент, но при этом стараетесь избежать конфликтов имен с элементами HTML-кода и функциями сценариев электронной панели, вы можете использовать уникальные идентификаторы портлетов. Для DDB-механизма это идентификатор с именем _WPID_, в Java Portlet API существует специальный объект Portlet, уникальный идентификатор которого хранится в свойстве ID.

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

Настраиваемый портальный компонент должен удовлетворять следующим трем условиям: он должен предоставлять пользователю способ для настройки; он должен где-то хранить информацию о своих настройках и иметь возможность извлечь эту информацию. В случае DDB-компонентов, чтобы создать интерфейс, дающий пользователям возможность настройки DDB-компонента, используется свойство CustomizationLink. Хранить информацию о настройках можно на клиенте, на сервере или в самом DDB-компоненте, используя для этого свойство PartStorage. С портлетами Java возникает аналогичная ситуация. В дескрипторе развертывания должны быть указаны режимы, которые поддерживает портлет (сюда входят view, help, edit, configure), а сам портлет должен содержать методы, которые обрабатывают эти режимы.

Digital Dashboard или J2EE-портлеты.
Что лучше?

Таблица 3. Сравнительные характеристики DDB и JP.

Теперь давайте сравним Digital Dashboard и J2EE-портлеты. Технология Digital Dashboard от Microsoft используется уже несколько лет. С момента ее представления и выхода первой версии инструментов для разработки решений на ее основе (Digital Dashboard Resource Kit, DDRK) прошло уже больше трех лет. За это время технология Digital Dashboard получила широкое признание и распространение. Многие компании, например, Troop Law, Motorola, JD Edwards, Pacific Life и другие, создали на ее основе различные варианты электронных информационных панелей для решения корпоративных задач. Технология J2EE-портлетов только развивается, и до сих пор не существует ее официальной спецификации. Однако она имеет перспективу скоро стать официальным стандартом, который будут поддерживать в своих продуктах BEA, IBM, iPlanet, Oracle, Epicentric и Apache Software Foundation. С другой стороны, учитывая возможность исполнения на всех серверных платформах (где есть виртуальная машина Java, конечно), и поддержку практически всех типов браузеров (портал представляет собой просто набор HTML-страниц), ее распространение может достичь поистине громадных масштабов. Microsoft, напротив, позиционирует Digital Dashboard как составную часть Microsoft Office и, в особенности, Outlook. Другое отличие состоит в том, что служебные возможности DDB-компонентам предоставляются через аналогичные DDB-компоненты, которые входят в состав электронной информационной панели, а J2EE-портлеты используют те же возможности путем вызова функций Portlet API на сервере. Дополнительно Microsoft предоставляет различные типы хранилищ для DDB-компонентов, которые обсуждались в части, посвященной Microsoft Digtal Dashboard. Подведем итог в таблице 3.

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

Copyright © 1994-2016 ООО "К-Пресс"