Журнал ВРМ World

22 августа 2001

Эволюция портала электронного бизнеса

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

Необходимость портальной среды

Как и многие другие решения в области информационных технологий (IT), портальные приложения могут быть построены как снизу вверх, так и сверху вниз. Первый подход предполагает быструю разработку, позволяя каждой группе или отделу компании реализовать свой собственный портал, не задумываясь о таких проблемах, как интеграция портальных приложений в общую корпоративную архитектуру или создание единой бизнес-терминологии портала для всей организации. Второй вариант построения приложений идет в противоположном направлении, начинающемся с тщательной оценки корпоративных бизнес-требований и определения параметров портальной среды, позволяющей интеграцию портальных приложений в единое корпоративное решение. Какой же из подходов лучше? Ответ зависит от особенностей и IT-бюджетов конкретного предприятия и способности его отдела IT реализовать на предприятии общекорпоративные стандарты. В идеале хорошо бы использовать комбинацию обоих подходов. Следует попробовать реализовать индивидуальные портальные проекты, чтобы поэкспериментировать с реализацией портала и ускорить уточнение самых болезненных аспектов этого процесса, а также окупаемость инвестиций в него (ROI). В то же время эти точечные решения должны достаточно просто встраиваться в интегрированную портальную среду, как это показано на Рисунке 1. Как уже было сказано, такая среда, в свою очередь, должна иметь возможность адаптироваться к изменениям условий рынка и новым возможностям продуктов.

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

Поддержка электронного бизнеса

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

Смещение интереса в область порталов электронного бизнеса привело к тому, что поставщики портальных решений стали поддерживать дополнительный бизнес-контент - например, бизнес-анализ (BI), электронную почту, офисные документы, электронный бизнес и приложения бэк-офиса и фронт-офиса. По мере развития портальных продуктов поставщиками им будет все труднее поддерживать такой широкий спектр услуг и бизнес-контента, как это требуется пользователям. Для решения этой проблемы многие поставщики сегодня предлагают пакеты для разработки портала (PDKs), обеспечивающие разработчикам возможность расширения портальных продуктов в соответствии с требованиями бизнеса и технологий (см. Рисунок 2).

Больше чем просто web-интерфейс

Основной задачей портала является обеспечение каждому пользователю персонализированного и интегрированного представления корпоративной информации и приложений. Для ее достижения портал должен предлагать нечто большее, чем просто web-интерфейс к бизнес-контенту. Он также должен содержать богатый спектр инструментов для сбора, систематизации, интеграции и персонализации этого контента. Эти сервисы должны иметь открытые интерфейсы, совместимые с PDK, для настройки и расширения портальной среды. Эти интерфейсы вместе с PDK образуют краеугольный камень платформы для разработки портала. Основные компоненты идеальной платформы для разработки портала показаны на Рисунке 3.

Компонента презентационных сервисов работает как главный интерфейс между пользователем портала и самим порталом. В настоящее время большинство порталов взаимодействуют с пользователями портала с помощью HTML, направляемом на рабочие столы клиентских компьютеров, имеющих броузеры (например, Microsoft Internet Explorer или Netscape Communicator). В ряде продуктов для расширения возможностей пользовательского интерфейса используется ActiveX или Java. Большинство портальных продуктов позволяют настроить интерфейсы под потребности конкретного пользователя. Рост популярности мобильных и радиоустройств потребует от портальных продуктов поддержки широкого спектра web-средств. Для решения этой задачи не нужно постоянно дополнять поддержку каждого нового типа устройств, достаточно обеспечить разработчикам в рамках PDK сервисы и средства, позволяющие быстро и просто встраивать web-устройства с использованием таких технологий, как XML-формат данных, таблицы стилей на расширяемом языке таблиц стилей (extensible stylesheet language, XSL) и стандартные для данной области бизнеса протоколы беспроводной связи.

Компонента пользовательских сервисов контролирует процесс обращения и доступа бизнес-пользователей (и других портальных компонент) к бизнес-контенту. Ключевыми сервисами этой компоненты являются следующие:

• Сервисы персонализации, предназначенные для фильтрации бизнес-контента в соответствии с интересами конкретных пользователей портала.
• Сервисы безопасности, предназначенные для поддержки стандартов безопасности организации и позволяющие пользователям просматривать только тот бизнес-контент, к просмотру которого они авторизованы. Этот аспект портала становится все более важным с расширением и углублением бизнес-контента и предоставления доступа к нему внешним пользователям.
• Сервисы публикации, обеспечивающие бизнес-пользователям интерактивный механизм документирования местонахождения и содержания бизнес-контента портала для совместного доступа и использования другими пользователями. Такая документация, или метаданные, хранится в каталоге портала, который, для упрощения доступа, разбивает метаданные по предметным областям. Ряд продуктов поддерживают перемещение опубликованного контента в хранилища портального контента коллективного доступа. Эта возможность особенно полезна в случае публикации информации, хранящейся на личном компьютере пользователя. Такую информацию можно переместить в управляемую среду коллективного доступа.
• Сервисы доступа и поиска, обеспечивающие пользователей возможностью поиска и доступа к бизнес-контенту. Пользователь просматривает каталог портала для поиска интересующих его моментов и затем использует информацию в метаданных для определения местонахождения и доступа к соответствующему бизнес-контенту. Просмотр метаданных может производиться путем навигации в рамках каталога портала или путем запросов к каталогу портала через сервисы поиска. Ряд продуктов предлагает еще и поисковые системы, способные находить нужный бизнес-контент в дополнение к записям каталога портала.
• Сервисы подписки и извещения, обеспечивающие пользователей портала бизнес-информацией, поставляемой на регулярной основе (например, в конце каждого рабочего дня) или извещающие (по электронной почте или сообщениями на домашней странице пользователя на портале) о появлении нового бизнес-контента или изменениях старого. График доставки и правила извещения для каждого подписчика хранятся в пользовательском профайле в каталоге портала.
• Сервисы совместной работы, предлагающие средства, позволяющие пользователям портала общаться между собой. Примерами таких сервисов могут служить календарное распределение (calendar sharing), чаты, новостные группы и онлайновые конференции.
• Сервисы технологического процесса, предназначенные для определения пользователями портала пакета взаимосвязанных бизнес-задач. Каждая задача в процессе работы инициируется по завершении соответствующей предыдущей задачи технологического процесса. Для доступа к информации, запуска приложений, рассылки сообщений и создания операционных транзакций эти задачи могут использовать портальные сервисы.

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

Записи каталога портала обычно организованы в соответствии с предметными областями, и каждый предмет связан с конкретной темой или понятием. Систематика бизнеса, определяющая структуру предметных областей, разрабатывается в процессе проектирования портала и представляет собой один из важнейших элементов в разработке портала и последующей работе с ним. Для систематизации, при определении предметных областей, наилучшим образом отвечающих метаданным контента, менеджер категоризации использует бизнес-правила. Правила систематизации оцениваются менеджером категоризации согласно информации, извлеченной из самого бизнес-котнтента либо из его метаданных (наименования приложения, имени файла, 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-приложений.

Эволюция порталов

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

• Поддержка приложений для корпоративных транзакций (унаследованных систем, фронт- и бэк-офисных пакетных приложений, приложений электронного бизнеса) с использованием пользовательских адаптеров контента портала или программного обеспечения для EAI сторонних поставщиков.
• Поддержка широкого спектра бизнес-информации (инструментов бизнес-анализа, систем управления контентом, данных баз данных, офисных документов, web-информации, объединенных данных) с помощью пользовательских адаптеров контента портала.
• Создание пакетов для разработки порталов (portal development kits, PDKs), обеспечивающих IT-разработчикам, провайдерам Интернет-сервиса и системным интеграторам возможность добавления и настройки адаптеров портала для доступа к бизнес-контенту. В качестве примера продуктов можно назвать Ascential Axielle менеджер типов, портальные модули Epicentric modules, портлеты (интерфейсные средства работы с приложениями через единый web-интерфейс) IBM WebSphere Portal Server, элементы Microsoft Web, портлеты Oracle, средства Plumtree, портлеты TopTier iViews и Viador. Важным моментом здесь является то, что большинство PDK поддерживают документированные, но собственные интерфейсы, что означает, что адаптеры не являются общими для этих продуктов. Java Apache Project опубликовал открытый интерфейс адаптера портала на основе XML (известный как Jetspeed), однако, кроме IBM, почти никто его не поддержал. Ряд поставщиков работают над поддержкой адаптеров других поставщиков. Например, Plumtree сотрудничает с Microsoft в разработке средств Plumtree Gadgets и элементов Microsoft Web, работающих в портальных средах обоих производителей. TopTier (недавно приобретенный SAP) совместно с Microsoft работал над совместимостью TopTier iViews и элементов Microsoft Web.
• Поддержка широкого спектра web-устройств, включая и мобильные и радиоустройства, с использованием таких технологий, как XML и XSL. Примерами продуктов для поддержки мобильных и радиоустройств здесь являются Corechange Coreport 3g, IBM WebSphere Everyplace Suite и Oracle Oracle9iAS Wireless Edition.
• Интеграция портальных технологий в web-приложения и коммерческие сервера. В качестве примеров продуктов можно назвать BroadVision InfoExchange Portal, IBM WebSphere Portal Server, Oracle Oracle9iAS Server и Sun iPlanet Portal Server.
• Интеграция портальных технологий в групоовое программное обеспечение и офисные решения. Ключевыми примерами являются Lotus Knowledge Discovery System, Microsoft SharePoint Portal Server и Correlate K-Maps для Lotus и Microsoft.
• Расширение функциональности портальных продуктов в области безопасности, поисковых сервисов, обработки правил, поддержки метаданных, технологического процесса и сотрудничества. Примерами здесь будут Ascential Axielle (управление метаданными), Microsoft (сервисы поиска и совместной работы), Verity Portal One (поисковые сервисы) и Viador E- Portal (безопасность).
• Интеграция портальных технологий в вертикальные пакеты приложений. В качестве лидеров рынка здесь можно привести Oracle, PeopleSoft и SAP.
• Объединение данной области рынка за счет слияний и приобретений. Примерами могут служить TopTier (приобретенный SAP для образования SAP Portals, Inc.) и Sequoia Software (приобретенный Citrix Software).
Ни один из имеющихся сегодня на рынке портальных продуктов не отвечает всем без исключения требованиям портального решения, и поэтому при оценке портальных продуктов следует рассматривать соответствие их возможностей требованиям приложений и выбирать те продукты, которые обеспечивают поддержку открытой портальной среды.