WSRP: интеграция портлетов в порталы

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

В августе 2003 года в области портальных технологий произошло событие, которое, соглашаясь с оценкой президента компании Delphi Group Томаса Коулопалоса, можно отнести к числу поворотных. Члены консорциума по стандартам OASIS утвердили первую версию нового стандарта WSRP (Web Services for Remote Portlets), определяющего, как порталы и Web-сервисы должны взаимодействовать друг с другом [1, 2]. На примере популярных программных продуктов IBM WebSphere Portal и Plumtree Portal мы рассмотрим существующие варианты интеграции приложений в порталы, покажем, почему возникла необходимость разработки WSRP, выясним основные положения нового стандарта.

Договоримся о терминах

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

Web-cервисом будем называть доступный в Сети программный компонент, поддерживающий стандарты UDDI, WSDL и SOAP. Стандарт UDDI помогает Web-сервис найти, WSDL — его охарактеризовать, а SOAP — взаимодействовать с ним. В мире Internet масса компонентов, которые могут быть доступны: HTML-страницы, программы, работающие по интерфейсу CGI, программы ASP/PHP/JSP, наконец, сервлеты, однако все они не являются Web-сервисами, поскольку не поддерживают совокупность указанных выше стандартов.

(В приведенном определении базовой характеристикой Web-сервиса является использование им протокола SOAP. Однако существует и более широкое понимание того, что следует понимать под Web-сервисом. В частности, альтернативу стандартному подходу, основанному на стеке «трех протоколов», предлагает архитектура REST [3].)

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

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

Существует формальное деление портлетов на две группы — локальные и удаленные. Портлет называют локальным, если он выполняется в среде портала. Для программного обеспечения IBM WebSphere Portal такой средой является сервер приложений IBM WebSphere Application Server. Среда выполнения портлета Plumtree зависит от версии портала и операционной системы. В обоих случаях локальный портлет обладает возможностью полного доступа к встроенным объектам портала через его API. В случае IBM WebSphere Portal локальный портлет получает также доступ к возможностям сервера приложений IBM.

В определении удаленного портлета могут встречаться различия. В частности, IBM WebSphere Portal считает портлет удаленным, если он выполняется на удаленном сервере и оформлен как Web-сервис [4]. В Plumtree Portal портлет может быть удаленным, даже если он физически размещен на машине, на которой работает портал. Размещенный же на другом сервере, удаленный портлет Plumtree не обязан быть оформлен как Web-сервис [5].

Стандарт WSRP вводит новое понятие. WSRP-сервис — это презентационно-ориентированный Web-сервис, который может быть использован любым заинтересованным в нем клиентским приложением [2]. Для этого WSRP-сервис имеет специальные «презентационные» интерфейсы, которые и специфицируются в стандарте WSRP. Остановимся на основных положениях стандарта подробнее.

Варианты «классической» интеграции

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

Рис. 1. Интеграция удаленного приложения посредством локального портлета

В такой интеграции участвуют четыре компонента: приложение, адаптер приложения на стороне портала, портлет и сам портал в качестве модуля агрегации данных. Приложение выступает поставщиком информации, и в общем случае нет никаких формальных ограничений относительно того, как эти данные должны быть представлены и переданы от источника к потребителю. Поэтому приложение должно иметь своего «представителя» на стороне портала — адаптер приложения, который берет на себя все тонкости общения с приложением. В качестве базового протокола используется TCP/IP, а протокол верхнего уровня может быть любым: DCOM, RMI или собственный протокол приложения. Непосредственно с адаптером общается портлет, который через интерфейсы адаптера получает данные, обрабатывает их на уровне логики задачи, формирует «презентационные» данные и направляет результат порталу. Портал объединяет результаты, полученные от разных портлетов, и отсылает их клиенту. В рассмотренном варианте портлет отвечает как за логику задачи, так и за способ представления результатов. Оба рассматриваемых нами варианта портального программного обеспечения поддерживают такую схему интеграции.

Рис. 2. Интеграция удаленного приложения посредством удаленного портлета

Рассмотрим теперь интеграцию приложения посредством удаленного портлета. Основной идеей такого подхода является вынос функций портлета на удаленный сервер. На рис. 2 показана общая схема интеграции удаленного приложения посредством удаленного портлета. На схеме преведено два варианта интеграции:

• удаленный портлет как Web-сервис;
• удаленный портлет как удаленная программа.

В первом случае на стороне портала присутствует модуль (портлет 1), который общается с Web-сервисом, получает от него обработанные на уровне логики данные, формирует «презентационный» уровень и отсылает его порталу. Во втором случае, как и в случае локального портлета, сам портлет содержит как логику задачи, так и способ представления результатов. Достигается это за счет адаптера портала, который обеспечивает доступ к пользовательским установкам портлета, хранящимся в базе данных портала, и прием текущих данных от пользователя (стандартным образом, по протоколу HTTP). Портлет может также формировать результат в формате HTML или XML.

Первый вариант интеграции, через Web-сервис, возможен как для IBM WebSphere Portal, так и для Plumtree Portal. Вариант интеграции через удаленную программу предусмотрен в Plumtree Portal.

Рассмотрим теперь конкретный пример интеграции систем документооборота Documentum и Open Text LiveLink. Покажем, какие средства интеграции предоставляют нам системы документооборота, и как ими воспользоваться в порталах.

В случае с Documentum в качестве адаптера источника данных выступает библиотека DFC (Documentum Foundation Class Library), которая инкапсулирует в себе все тонкости общения с сервером Documentum. Интерфейсы DFC могут напрямую вызываться из Java, либо из скриптовых языков (например, ASP) посредством COM. Это означает, что Documentum имеет широкие возможности интеграции и не накладывает существенных ограничений на язык программирования, на котором создается портлет.

При интеграции в IBM WebSphere Portal, если портлет локальный, портал выдвигает требования к языку программирования портлета. В данном случае это Java, который удачно сочетается с возможностью прямой работы с интерфейсами DFC. Если портлет удаленный, единственным требованием выступает оформление портлета в виде Web-сервиса. Как Web-сервис будет общаться с Documentum, и на каком языке он написан, порталу не важно.

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

Похожим образом проходит интеграция системы документооборота OpenText LiveLink. В качестве адаптера источника данных здесь выступает LAPI (Livelink Application Programming Interface). Доступ к LAPI возможен на языках программирования C++, Java, Visual Basic, а также через Microsoft .NET (в этом случае могут использоваться C#, Managed С++ и VB). Однако в отличие от Documentum, здесь невозможен доступ посредством COM, что делает невозможной интеграцию через скриптовые языки.

Итак, рассмотрены «классические» варианты интеграции приложений в портальные системы. Какие можно сделать выводы? Во-первых, такая интеграция требует обязательного написания портлета, который будет общаться с адаптером приложения. Во-вторых, адаптер приложения требуется установить на портал или удаленный сервер, а в некоторых случаях разработать его. В-третьих, если имеется N приложений, то в общем случае эти действия требуется повторить N раз. И самое главное, все вышеперечисленное возможно, только если это позволяют как портальная платформа, так и само приложение. Таким образом, мотивов для появления нового стандарта было предостаточно.

Интеграция по WSRP

Разработка стандарта WSRP была инициирована группой компаний, входящих в консорциум по стандартам OASIS. Консорциум, созданный в 1993 году, первоначально имел довольно узкую цель по выработке общих правил работы с языком разметки SGML и поэтому получил соответствующее наименование — SGML Open. В 1998 году спектр стоящих перед ним задач был расширен; появился OASIS.

Непосредственно разработкой стандарта WSRP занимались специалисты, входящие в две технические подгруппы OASIS — WSIA (Web-сервисы для интерактивных приложений) и WSRP (Web-сервисы для удаленных портлетов). Работа началась весной 2002 года и продолжается по настоящее время. Следующей задачей за утверждением первой версии стандарта является разработка версии 1.1, выход которой планируется весной 2004 года. Наиболее интересным новшеством версии 1.1 станет включение в WSRP правил по работе со специализированными языками разметки VoiceXML и WML.

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

Первая задача решалась соглашением о том, что WSRP-сервисы являются Web-cервисами, следовательно, в основе работы с ними лежит стек протоколов UDDI, WSDL и SOAP. Вторая задача решалась разработкой и согласованием «презентационных» WSRP-интерфейсов. Интеграция по стандарту WSRP показана на рис. 3.

Рис. 3. Интеграция по стандарту WSRP

В свое время технология COM позволила создавать внешние интерфейсы для приложений, содержащих объектно-ориентированные структуры выходных данных произвольной сложности. Похожим образом новый стандарт определяет структуры данных и интерфейсы, позволяющие удаленным приложениям предоставлять свои данные универсальным способом, через WSRP-сервисы. Например, для получения данных от сервиса необходимо использовать интерфейс getMarkup(). Один из параметров этого интерфейса позволяет передать информацию о том, в каком виде пользователь (в нашем случае портал) желает видеть возвращаемые сервисом данные. По спецификации сервис может вернуть данные в любом из имеющихся типов данных MIME [6]. Можно даже определить массив, который в приоритетном порядке будет содержать желательные для возврата типы данных.

Если сервис не поддерживает, скажем, графический интерфейс, то данные могут быть возвращены в виде HTML-таблицы или в формате XML. Кроме того, первая версия стандарта закладывает основы его дальнейшего развития, рассматривая более сложные ситуации: реакция WSRP-сервисов на действия пользователей, сохранение промежуточных состояний сервиса, обработка ошибок, передача данных в двоичном виде, шифрование и др. В частности, интерактивная работа подразумевает сохранение текущих пользовательских установок; следовательно, необходимо контролировать состояние текущего сеанса для данного WSRP-сервиса. WSRP-сервисы могут иметь и конфигурационные установки. Стандарт указывает способ сохранения и получения таких установок через представителя WSRP-сервиса на портале, т.е. WSRP-портлета. Жизненный цикл WSRP-сервиса, технология публикации сервиса, вопросы кэширования — все это рассматривается в спецификации [2]; популярное изложение можно найти в [7].

Привлекательность WSRP-интеграции заключается еще и в том, что WSRP-совместимый портал имеет встроенный модуль, который берет на себя функции поиска и встраивания WSRP-сервисов. Результатом его работы является автоматически сгенерированный представитель WSRP-сервиса на портале — WSRP-портлет (Portlet proxy). Таким образом, интеграция приложений через WSRP-сервисы осуществляется административными средствами портала, никаких дополнительных усилий по разработке промежуточных модулей теперь не требуется.

Развитие этого сектора рынка настолько стремительно, что еще до окончательного утверждения стандарта некоторые компании производители портальных решений заявили о включении в свои продукты модулей, расширяющих их портальные платформы поддержкой WSRP. Так, IBM WebSphere Portal 5.0 поддерживает WSRP с начала 2003 года, а компания Plumtree сообщила о разработке соответствующего модуля, Plumtree WSRP Portlet Consumer, сразу после утверждения стандарта. В отличие от других портальных решений и в соответствии с общей архитектурой платформы Plumtree, WSRP-модуль может быть установлен и работать не только в среде портала, но и на удаленном сервере, выступая промежуточным звеном между порталом и WSRP сервисом. Такое решение обладает масштабируемостью и гибкостью, поскольку освобождает портал от дополнительной нагрузки, а также увеличивает общую надежность работы портала за счет уменьшения риска от подключения нового сервиса.

Одним из самых последних по времени усилий, предпринятых компаниями, заинтересованными в продвижении стандарта WSRP, является организация в Internet сайта POST (Portlet Open Source Trading — portlet-opensrc.sourceforge.net). Данный сайт, организованный усилиями компаний Plumtree, Documentum, BEA Systems и Sun Microsystems, предназначен для обмена опытом между разработчиками WSRP-портлетов и позволяет потенциальным потребителям WSRP-сервисов получить к ним свободный доступ.

Заключение

Мы рассмотрели схемы интеграции, которые применяются сегодня при встраивании внешних приложений в порталы, показали усилия, необходимые для осуществления интеграции по «классическим» схемам, продемонстрировали основные идеи, лежащие в основе WSRP-стандарта. Еще раз подчеркнем ключевое достоинство WSRP-сервисов — они доступны для автоматического подключения к любому WSRP-совместимому порталу. Разработчик WSRP-сервиса или WSRP-портлета может не беспокоиться о портальной платформе потенциального клиента, поскольку такой сервис будет доступен любому порталу.

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

Литература

1. Newsletter, N 5. http://www.drecommerce.com/doc/KTweb_Newsletter_Jul-Sep_2003.pdf.
2. Services for Remote Portlets Specification. http://www.oasis-open.org/committees/wsrp.
3. Леонид Черняк, "SOAP и REST, вместе или порознь?" // Открытые системы, № 9, 2003.
4. WebSphere Portal V 4.1. Handbook, Volume 2.
5. Plumtree Gadget Web Services. Design and Development.
6. Media Types, http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.
7. Services for Remote Portlets (WSRP). White Paper.