В наши дни интенсивность использования порталов растет так же быстро, как и ширится число портальных продуктов. С насыщением рынка становится актуальным отслеживание судьбы тех или иных продуктов. Ввиду нестабильности этой области бизнеса, организациям следует строить гибкие портальные среды, способные адаптироваться к изменениям рынка и развитию функциональности соответствующих продуктов. Портальная среда способна помочь и в вопросах интеграции, поскольку портальная технология пересекается со смежными областями программного обеспечения - например, серверами web-приложений, пакетами для электронной коммерции, программами для интеграции корпоративных приложений и др. Эта статья имеет целью облегчить читателям систематизацию присутствующих сегодня на рынке решений и планирование реализации собственного портала, предоставляя обзор текущего состояния портальной технологии и описывая гибкую среду для запуска портальных приложений.
Как и многие другие решения в области информационных технологий (IT), портальные приложения могут быть построены как снизу вверх, так и сверху вниз. Первый подход предполагает быструю разработку, позволяя каждой группе или отделу компании реализовать свой собственный портал, не задумываясь о таких проблемах, как интеграция портальных приложений в общую корпоративную архитектуру или создание единой бизнес-терминологии портала для всей организации. Второй вариант построения приложений идет в противоположном направлении, начинающемся с тщательной оценки корпоративных бизнес-требований и определения параметров портальной среды, позволяющей интеграцию портальных приложений в единое корпоративное решение. Какой же из подходов лучше? Ответ зависит от особенностей и IT-бюджетов конкретного предприятия и способности его отдела IT реализовать на предприятии общекорпоративные стандарты. В идеале хорошо бы использовать комбинацию обоих подходов. Следует попробовать реализовать индивидуальные портальные проекты, чтобы поэкспериментировать с реализацией портала и ускорить уточнение самых болезненных аспектов этого процесса, а также окупаемость инвестиций в него (ROI). В то же время эти точечные решения должны достаточно просто встраиваться в интегрированную портальную среду, как это показано на Рисунке 1. Как уже было сказано, такая среда, в свою очередь, должна иметь возможность адаптироваться к изменениям условий рынка и новым возможностям продуктов.
Для поддержки интегрированной портальной среды продукты могут предоставлять платформу для разработки с открытыми интерфейсами и сервисами, предлагающими разработчикам возможность настройки и web-интерфейса для пользователей портала и портальные адаптеры, используемые для доступа к бизнес-информации и приложениям. Подробнее требования к платформе для разработки портала будут рассмотрены далее.
Большинство компаний начинают с построения внутреннего корпоративного портала, обеспечивающего сотрудникам и бизнес-пользователям персонализированное представление информации в корпоративном Интранете. Популярность электронного бизнеса, тем не менее, привела к тому, что многие организации интегрируют портальную технологию в свои системы и приложения электронного бизнеса. Портал электронного бизнеса обеспечивает компании расширение портального доступа к внешним торговым партнерам, поставщикам и клиентам, что способствует улучшению бизнес-отношений и налаживанию связей.
Смещение интереса в область порталов электронного бизнеса привело к тому, что поставщики портальных решений стали поддерживать дополнительный бизнес-контент - например, бизнес-анализ (BI), электронную почту, офисные документы, электронный бизнес и приложения бэк-офиса и фронт-офиса. По мере развития портальных продуктов поставщиками им будет все труднее поддерживать такой широкий спектр услуг и бизнес-контента, как это требуется пользователям. Для решения этой проблемы многие поставщики сегодня предлагают пакеты для разработки портала (PDKs), обеспечивающие разработчикам возможность расширения портальных продуктов в соответствии с требованиями бизнеса и технологий (см. Рисунок 2).
Основной задачей портала является обеспечение каждому пользователю персонализированного и интегрированного представления корпоративной информации и приложений. Для ее достижения портал должен предлагать нечто большее, чем просто web-интерфейс к бизнес-контенту. Он также должен содержать богатый спектр инструментов для сбора, систематизации, интеграции и персонализации этого контента. Эти сервисы должны иметь открытые интерфейсы, совместимые с PDK, для настройки и расширения портальной среды. Эти интерфейсы вместе с PDK образуют краеугольный камень платформы для разработки портала. Основные компоненты идеальной платформы для разработки портала показаны на Рисунке 3.
Компонента презентационных сервисов работает как главный интерфейс между пользователем портала и самим порталом. В настоящее время большинство порталов взаимодействуют с пользователями портала с помощью HTML, направляемом на рабочие столы клиентских компьютеров, имеющих броузеры (например, Microsoft Internet Explorer или Netscape Communicator). В ряде продуктов для расширения возможностей пользовательского интерфейса используется ActiveX или Java. Большинство портальных продуктов позволяют настроить интерфейсы под потребности конкретного пользователя. Рост популярности мобильных и радиоустройств потребует от портальных продуктов поддержки широкого спектра web-средств. Для решения этой задачи не нужно постоянно дополнять поддержку каждого нового типа устройств, достаточно обеспечить разработчикам в рамках PDK сервисы и средства, позволяющие быстро и просто встраивать web-устройства с использованием таких технологий, как XML-формат данных, таблицы стилей на расширяемом языке таблиц стилей (extensible stylesheet language, XSL) и стандартные для данной области бизнеса протоколы беспроводной связи.
Компонента пользовательских сервисов контролирует процесс обращения и доступа бизнес-пользователей (и других портальных компонент) к бизнес-контенту. Ключевыми сервисами этой компоненты являются следующие:
Компонента управления контентом отвечает за администрирование каталога портала и хранилища контента. Каталог портала является краеугольным камнем портала, так как он выполняет функцию карты для всей области (домена) бизнес-контента (т.е. информации, приложений и т.п.), доступной для просмотра бизнес-пользователям. Документация, или метаданные, по этому бизнес-контенту поддерживается в каталоге портала с помощью интерфейса, способного использовать одновременно и портальные и внешние сервисы и инструменты для создания и модификации записей в каталоге портала.
Записи каталога портала обычно организованы в соответствии с предметными областями, и каждый предмет связан с конкретной темой или понятием. Систематика бизнеса, определяющая структуру предметных областей, разрабатывается в процессе проектирования портала и представляет собой один из важнейших элементов в разработке портала и последующей работе с ним. Для систематизации, при определении предметных областей, наилучшим образом отвечающих метаданным контента, менеджер категоризации использует бизнес-правила. Правила систематизации оцениваются менеджером категоризации согласно информации, извлеченной из самого бизнес-котнтента либо из его метаданных (наименования приложения, имени файла, URL web-страницы, автора и др.). Сервисы (например, сервисы публикации) и инструменты, использующие интерфейс каталога портала, могут применять менеджер категоризации для распределения записей каталога портала по соответствующим им предметным областям.
Продукты могут довольно существенно отличаться друг от друга по возможностям своего каталога портала и категоризационного менеджера и по типам поддерживаемых ими в каталоге портала метаданных. Ряд продуктов просто документируют имена и расположение контента, другие поддерживают более подробную информацию о его бизнес-значении и использовании. Аналогично, некоторые продукты содержат мощные автоматические менеджеры категоризации, тогда как в других категоризация возможна только вручную. Функциональные возможности каталога портала и категоризационного менеджера являются ключевыми отличительными свойствами продуктов.
Компонента адаптеров контента портала содержит пакет сервисов для сбора информации о бизнес-контенте и для доступа к этому контенту. Как уже было сказано, информация о бизнес-контенте, доступная через портал, хранится в виде метаданных в каталоге портала. Адаптеры портала могут иметь различные формы. В качестве примера таких адаптеров можно назвать программируемые интерфейсы, механизмы импорта и экспорта файлов и автоматизированные средства (иногда называемые "червями" (crawlers)), сканирующие бизнес-контент через определенные промежутки времени. Портал может иметь адаптеры для баз данных и файлов, бизнес-аналитических (BI) продуктов, контента и систем управления документами, программное обеспечение автоматизации коллективной работы и офисные объекты (например, электронную почту, документы с пословной обработкой текста, крупноформатные таблицы и web-страницы) или приложения (для фронт-офиса, бэк-офиса и электронного бизнеса).
Адаптеры контента портала также различаются по своим возможностям. Некоторые могут состоять из остаточных групповых баз данных или файловых интерфейсов, другие же плотно интегрированы в исходный контент (например, коммерческое приложение электронного бизнеса). При выборе продуктов число предоставляемых порталом адаптеров несущественно, важными являются возможности каждого из этих адаптеров. Более мощные адаптеры добавляются к портальным продуктам поставщиками. В качестве примера приведем адаптеры для программного обеспечения взаимодействия с программным обеспечением для интеграции корпоративных приложений (EAI), для извлечения текста, каталогизационной экспертизы и отслеживания отношений между различными квалификациями на основе эксплуатационных характеристик.
Разработчики порталов могут дополнять порталы адаптерами контента с помощью пакета для разработки порталов. PDK должен обеспечивать функциональные возможности, позволяющие писать упаковщики на Java или Microsoft ActiveX для доступа к бизнес-контенту и представления этого контента и связанных с ним метаданных в портале в форме потока данных на основе XML. Кроме того, для построения сложных вертикальных порталов, предназначенных для управления отношениями между различными типами бизнес-контента и бизнес-обработки, PDK должен поддерживать адаптеры контента, взаимодействующие с другими сервисами портала. Для разработки вертикального портала, управляющего потоком бизнес-контента между различными пользователями портала, адаптер контента портала может, например, требовать взаимодействия с сервисами технологического процесса. Такие типы приложений вертикальных порталов разрабатываются независимыми поставщиками программного обеспечения (independent software vendors, ISVs) и настраиваются самим потребителями в соответствии с их специфическим потребностями. Пакетные приложения вертикальных порталов строятся с использованием открытой платформы для разработки портала, существенно уменьшающей объем работ реализации и интеграции портала.
Многие порталы взаимодействуют с бизнес-пользователями через web-интерфейс. Содержащиеся в нем web-сервисы могут включаться в инфраструктуру самого портала, однако продукты обычно используют для такой обработки отдельный web-сервер. Возможности этого web-сервера, используемые портальными продуктами, различны - начиная с простых сервисов-приемников http, до использования web-сервера в средствах администрирования и разработки, в вопросах безопасности и в качестве интерфейса к серверным хранилищам бизнес-контента. Хотя портальным продуктам выгодно поддерживать возможности работы с наиболее популярными web-серверами, не менее важно, чтобы продукты содержали такие функции, как сервисы каталогов, кэширование, баланс загрузки и failover (автоматическое переключение на резервный сервер, систему или сеть в результате сбоя или аварийного прерывания работы основного сервера, системы или сети) в серверах web-приложений.
Портальные продукты эволюционируют достаточно быстро. В процессе развития этого рынка можно выявить следующие основные тенденции: