17 августа 2019 года    
Суббота | 16:59    
Главная
 Новости
Базы данных
Безопасность PC
Всё о компьютерах
Графика и дизайн
Интернет-технологии
Мобильные устройства
Операционные системы
Программирование
Программы
Связь
Сети
 Документация
Статьи
Самоучители
 Общение
Форум







Разделы / Интернет-технологии / XML

Построение XML-порталов на основе Cocoon

Построение XML-порталов на основе Cocoon

Введение

В 1998 году Stefano Mazzocchi, окончательно разочаровавшись в ограниченных возможностях HTML в области отделения контента от представления, инициировал разработку Apache Cocoon. Текущее состояние проекта подробно описано им статье, опубликованной на сайте XML.com.

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

Новые компоненты изначально были разработаны как часть коммерческого предложения. Так, в середине 2001 года мы установили первый портал на основе Cocoon в одном финансовом учреждении в Германии. Однако, в начале 2002 года мы передали наши наработки проекту Cocoon. В их числе были компоненты и средства для аутентификации (под названием "sunRise") и для построения порталов (под названием "sunSpot"). Каждый из этих элементов можно использовать отдельно от другого. Например, средства аутентификации можно использовать для защиты некоторых ресурсов на сервере.

Аутентификация

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

Задача

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

Решение

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

Концепция аутентификации на основе обработчиков используется для логической группировки ресурсов. Это означает, что если пользователь прошел процедуру аутентификации в некотором обработчике, то он получает доступ ко всем ресурсам, которые находятся в логической группе этого обработчика. Каждый обработчик можно настроить на проведение процедуры аутентификации через конкретный источник данных. Например, обработчик A может использовать базу данных, а обработчик B может использовать директорию LDAP. На самом деле, процедура аутентификации работает на основе системы компонент Cocoon.

Ниже приводится фрагмент карты сайта Cocoon, где показано, как настроен обработчик.

<map:pipelines>
    <map:component-configurations>
        <authentication-manager>
            <handlers>
                <handler name="portalhandler">
                    <redirect-to uri="cocoon:/sunspotdemoportal"/>
                    <authentication uri="
                        cocoon:raw:/sunrise-authuser"/>
                </handler>
            </handlers>
        </authentication-manager>
    </map:component-configurations>
    ...
</map:pipelines>

Различные обработчики сгруппированы внутри секции authentication-manager. При этом каждый обработчик имеет уникальное имя. Это имя позднее будет использоваться при настройке системы компонент, которую необходимо защитить. При настройке системы компонент с помощью тэга redirect-to можно указать, на какую страницу будет перенаправлен пользователь при попытке получить доступ к защищенной странице, для просмотра которой у него нет прав. Система компонент аутентификации определяется с помощью тэга authentication. Эта система компонент получает данные из формы, например, со страницы входа, а затем удостоверяет их правильность.

При успешной проверке система компонент аутентификации (в данном случае она называется "sunrise-authuser") возвращает XML-данные в специальном формате, который подробно описан в документации к Cocoon. Этот формат является достаточно гибким: дополнительные данные о пользователе можно добавить с помощью описываемой системы компонент и затем использовать в своем приложении.

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


<map:match pattern="protected-document">
    <!-- protect this document -->
    <map:act type="auth-protect">
        <map:parameter name="handler" value="portalhandler"/>

        <map:generate src="document.xml"/>
        <map:transform src="to_html.xsl"/>
        <map:serialize/>
    </map:act>
</map:match>

В нашем случае ресурс protected-document "принадлежит" обработчику portalhandler. Если пользователь "вошел" в этот обработчик, то все ресурсы, которые сгруппированы в нем, будут ему доступны. Если же пользователь не вошел в обработчик, то он будет перенаправлен на другую систему компонент, определенную при настройке обработчика. Обычно, в этом случае отображается страница входа, чтобы пользователь мог войти на портал, указав идентификатор и пароль.

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

Tool for user management

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

Портал

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

Когда мы начали разрабатывать порталы для наших клиентов, то поняли, что "коробочные" решения не являются достаточно гибкими для удовлетворения всех требований клиентов. Поскольку на данный момент возросла потребность в "многоканальных" решениях (где публикация возможна в различных форматах, таких как HTML, WML или PDF), и порталы должны иметь возможность работать с различным источникам данных, мы решили, что использование компонент портала в архитектуре Cocoon будет наилучшим решением.

Задача

Главная задача портала, построенного на базе Cocoon, заключается в полной поддержке самой концепции Cocoon, в частности, в гибком использовании систем компонент для доступа к различным источникам данных и применении XML внутри платформы. Решение должно предоставлять стандартную функциональность портала, такие как возможность настройки вида портала и вывод данных в удобной для пользователя форме. Конфигурация (доступные портлеты и т.п.) и вид портала должны быть описаны на XML. При создании шаблон портала следует использовать таблицы стилей, чтобы портал имел возможность генерировать вывод в различных форматах, таких как HTML, WML или даже PDF. Использование таблиц стилей при компоновке портала дает возможность более гибко управлять выводом на основе такой информации, как, например, тип используемого браузера.

Решение

Для аутентификации пользователей портала, в нашем портальном решении используется система компонент аутентификации Cocoon, описанная выше. Это позволяет работать с существующими базами данных пользователей для хранения информации о пользователях портала. Также портальное решение содержит дополнительные компоненты Cocoon для отображения портала и настройки. Доступ к различным источникам данных, называемых портлетами в большинстве портальных решений (в Cocoon они называются коплетами), можно реализовать посредством систем компонент, URI или даже классов Java, реализующих интерфейс коплета.

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

An example portal

Представление портала описано на XML. Когда пользователь "входит" в портал, выполняются различные действия, связанные со "сборкой" страниц специализированного портала. Процесс построения происходит в два этапа: определение коплетов и определение шаблона вывода портала. В следующем XML-фрагменте приводится определение коплета, который называется "sundnnews". Обратите внимание, как в определении resource uri указывается система компонент внутри карты сайта Cocoon. В этом примере показано, как можно использовать Cocoon в качестве источника для коплета.

<coplets-profile>
    <coplets>
        <coplet id="sundnnews">
             <resource uri="
                 cocoon:raw:/sunspotdemosunlet-onlinesundn.xml"/>
             <configuration>
                 <mandatory>false</mandatory>
                 <sizable>true</sizable>
                 <active>true</active>
             </configuration>
             <title>s&n News</title>
             <status>
                 <customize>false</customize>
                 <visible>true</visible>
                 <size>max</size>
             </status>
        </coplet>
        ...
    </coplets>
</coplets-profile>

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

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

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

Ниже приводится фрагмент реальной системы компонент карты сайта, на основе которой построен портал. Он содержит специализированную компоненту портала в качестве генератора. Также, как и любая система компонент Cocoon, реальный шаблон вывода для портала определяется с помощью таблиц стилей.

<map:match pattern="sunspotdemo-portal">
    <map:act type="auth-protect">
        <map:parameter name="handler" value="portalhandler"/>
        <map:parameter name="application" value="sunspotdemo"/>

	<map:generate type="portal"/>
        <map:transform src="styles/portalHTML.xsl"/>
        <map:serialize/>
    </map:act>
</map:match>

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

Tool for portal management

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

После того, как вы установили прототип портала, вы можете изменять его в соответствии с поставленными задачами. Вы можете добавить новые коплеты, определяя систему компонент внутри карты сайта Cocoon и добавляя эту систему в качества коплета с помощью соответствующих средств. Поскольку портал позволяет включать новые источники данных, используя системы компонент Cocoon или URI, вы можете создавать новые порталы без необходимости написания кода. Другая интересная деталь заключается в использовании дополнительных таблиц стилей в системе компонент отображения портала для изменения его внешнего вида. Cocoon предоставляет некоторые компоненты, такие как селекторы, которые можно использовать для выбора различных таблиц стилей в зависимости от типа браузера или других параметров (например, внешний вид портала может измениться после 8 часов вечера с помощью применения соответствующей таблицы стилей).

Заключение

Компоненты портала и аутентификации были добавлены в проект Cocoon в начале 2002. Несмотря на это, они уже активно используются некоторыми крупными компаниями в качестве основы для Intranet-решений. В частности, мы гордимся тем фактом, что NASA и некоторые крупные IT-компании, такие как BASF IT Services, отдали свои голоса в пользу open source технологии и XML-ориентированных решений для создания мощных корпоративных порталов. Поскольку портал тесно связан со всей XML-платформой публикации, он не нарушает концепцию Cocoon и позволяет использовать гибкие возможности публикации на основе XML-XSL.

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

Построение XML-порталов на основе Cocoon
Лента новостей


2006 (c) Copyright Hardline.ru