Введение в Web Services for Remote Portlets

Применение WSRP в Service-Oriented Architecture (ориентированной на службы архитектуре)

В статье дано введение в Web Services for Remote Portlets (WSRP), спецификацию, определяющую, как использовать основанные на SOAP Web-службы, генерирующие дополнительные фрагменты внутри приложения портала. Определяя набор интерфейсов общего назначения, WSRP позволяет порталам отображать выполняющиеся удаленно портлеты внутри своих страниц без дополнительного программирования разработчиками портала. Конечному пользователю кажется, что портлет выполняется локально внутри и его портала, но в действительности портлет располагается в работающем удаленно контейнере портлета, и взаимодействие происходит при помощи обмена SOAP-сообщениями. Использование WSRP в Service-Oriented Architecture обеспечивает мощную комбинацию, посредством которой ориентированные на представление приложения портлета могут быть обнаружены и повторно использованы без дополнительной разработки или дополнительных действий по развертыванию.

Bryan Castle, Старший консультант, Booz Allen Hamilton

Брайан Кастл (Bryan Castle) является старшим консультантом в Booz Allen Hamilton. Он специализируется на разработке основанных на Web-технологиях решений, включая Service-Oriented Architecture и технологии распределенных вычислений с использованием платформы J2EE.



15.04.2005

Обзор WSRP и родственных технологий

За последние пару лет термин Service Oriented Architecture (SOA) стал употребляться очень часто, хотя в этом понятии ничего фундаментально нового нет. И хотя SOA часто обсуждается внутри технического сообщества, как влияет SOA на конечного пользователя? Собирается ли конечный пользователь запрашивать каталог служб для поиска Web-службы, удовлетворяющей его требованиям? И как тогда конечный пользователь будет взаимодействовать с Web-службой, даже если он был предупрежден о ее существовании? Нужно ли писать клиентское приложение или UI для взаимодействия с Web-службой? Возможно, нет. Предоставляет ли SOA прямые преимущества конечному пользователю? Опять же, возможно нет – по крайней мере, до настоящего времени. WSRP является новой технологией, которая недавно получила поддержку от всех крупных игроков на рынке порталов, включая IBM™, BEA, Oracle и Microsoft®. Конечной целью WSRP является предоставление Web-служб и преимуществ Service-Oriented Architecture конечному пользователю.

Спецификация WSRP является продуктом международной организации Organization for the Advancement of Structured Information Standards (OASIS, Организация по развитию стандартизации структурированной информации), являющейся консорциумом, содействующим принятию технических стандартов. Версия 1.0 спецификации WSRP была закончена в августе 2003, и сейчас ведутся работы над версией 2.0, которая будет готова к середине 2005. Поскольку все главные игроки рынка порталов представлены в OASIS' WSRP Technical Committee, эта технология должна получить широкое распространение в отрасли. Спецификация OASIS WSRP определяет общий, строго определенный интерфейс для взаимодействия с подключаемыми, ориентированными на представление Web-службами. Эти службы занимаются взаимодействиями с пользователями и предоставляют фрагменты кода на языке разметки страниц для агрегирования порталами.

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

Стоит отметить, что WSRP построен на основе существующих стандартов Web-служб, таких как SOAP, WSDL и UDDI (см. раздел "Ресурсы"). И хотя данный документ концентрируется на наиболее общем сценарии использования WSRP (генерировании маркировочных фрагментов HTML для использования внутри портала), ничто не мешает WSRP транспортировать также и другие языки разметки. На рисунке 1 показано место WSRP в стеке технологий Web-служб.

Рисунок 1. WSRP основан на существующих технологиях Web-служб
WSRP основан на существующих технологиях Web-служб

Определение портала и портлета

Перед погружением в мир WSRP я должен сначала прояснить, что подразумевается под терминами портал и портлет. Определение портала является предметом для анализа; опрос десяти инженеров-программистов вероятно даст десять различных определений. Для целей данной статьи портал может быть представлен как Web-приложение, которое может быть настроено конечным пользователем как по внешнему виду и поведению, так и по доступным содержанию и содержащимся в портале приложениям. Более того, портал можно представить как объект, агрегирующий в себе содержимое и приложения, или как одну точку входа к пользовательскому набору инструментальных средств и приложений.

Теперь, когда вы знаете что такое портал, как точно определяется портлет? Портлет может быть представлен как миниатюрное Web-приложение, выполняющееся внутри страницы портала вместе с любым количеством таких же сущностей. Портлет - это Web-компонент, управляемый контейнером и способный обрабатывать запросы и генерировать динамическое содержимое (контент). Портлеты могут быть самыми разными – некоторые основаны на стандартах, другие принадлежат размещаемому их порталу. Спецификация Java Portlet Specification (JSR-168), принятая в октябре 2003, определяет стандартный API для порталов, основанных на платформе J2EE. Целью JSR-168 является предоставление набора стандартов, так чтобы любой совместимый портлет мог бы быть развернут на любом портале, поддерживающем спецификацию. На рисунке 2 показана традиционная модель портала, в которой имеется контейнер портлетов, содержащий любое количество отдельных портлетов. Каждый из этих портлетов генерирует фрагменты на языке разметки страниц, которые портал в конечном итоге соединяет вместе для создания цельной страницы, представляемой пользователю.

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

Зачем нужен WSRP?

Если Web-службы предлагают механизм создания платформо-независимых служб, а JSR-168 определяет стандарт разработки портлетов, зачем нужен WSRP? Ответ прост. Если Web-службы предоставляют возможность повторного использования внутренних служб, то WSRP дает возможность повторно использовать весь пользовательский интерфейс!

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

Делая то же самое с использованием WSRP, можно на много проще интегрировать портлет биржевых котировок в ваш портал. Можно самостоятельно выполнить поиск портлетов в UDDI-каталоге или предоставить такую возможность пользователям. После обнаружения нужного нам Stock Quote Portlet процесс добавления его в портал потребует только нескольких нажатий кнопки мыши, и все будет готово. Вам не нужно осуществлять какое-либо кодирование или развертывание, поскольку доступ к портлету осуществляется через WSRP. Конечному пользователю не нужно знать что-либо о WSRP или даже о том, что их портлет на самом деле размещен у удаленного поставщика! Пользователь знает только о том, что имеется каталог доступных портлетов, в котором он может выбрать нужный ему. Что может быть проще?


WSRP: За кулисами

WSRP - актеры

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

  • WSRP-поставщик: Это Web-служба, предлагающая один или несколько портлетов и реализующая набор WSRP-интерфейсов, предоставляя таким образом набор операций для потребителей. В зависимости от реализации поставщик может предлагать только один портлет, или предоставить среду исполнения (или контейнер) для развертывания и управления несколькими портлетами. WSRP-поставщик является истинной Web-службой, укомплектованной WSDL и набором граничных точек. Каждый поставщик в WSRP описан при помощи стандартного WSDL-документа.
  • WSRP-портлет: WSRP-портлет является подключаемым компонентом пользовательского интерфейса, выполняющимся внутри WSRP-поставщика, и доступ к которому осуществляется удаленно через интерфейс, определенный этим поставщиком. WSRP-портлет не является Web-службой в полном понимании этого слова (к нему нельзя получить доступ непосредственно, а только через его поставщика).
  • WSRP-потребитель: Это клиент Web-службы, который вызывает предлагаемые поставщиком WSRP Web-службы и предоставляет пользователям среду для взаимодействия с портлетами, предлагаемыми одним или несколькими поставщиками. Самым распространенным примером WSRP-потребителя является портал.
Рисунок 3. Портал, действующий как WSRP-потребитель для объединения фрагментов, полученных от удаленных портлетов
Портал, действующий как WSRP-потребитель для объединения фрагментов, полученных от удаленных портлетов

WSRP-интерфейсы

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

  • Service Description Interface (обязателен): Service Description Interface позволяет WSRP-поставщику проинформировать потенциальных потребителей о своих возможностях. WSRP-потребитель может использовать этот интерфейс для запроса о том, какие портлеты может предоставить поставщик, а также для запроса дополнительных метаданных о самом поставщике. Этот интерфейс может действовать как механизм обнаружения набора предлагаемых портлетов, но также дает возможность потребителям узнать дополнительную информацию о технических возможностях поставщика, что тоже важно. В метаданных поставщика может содержаться информация о возможной необходимости регистрации или инициализации куки перед тем, как потребитель сможет взаимодействовать с любым из портлетов.
  • Mark-up Interface (обязателен): Markup Interface предоставляет возможность взаимодействия WSRP-потребителя и портлета, выполняющегося удаленно у WSRP-поставщика. Например, потребитель мог бы использовать этот интерфейс для выполнения каких-либо действий при подтверждении пользователем формы на странице портала. Кроме того, порталу может понадобиться просто получить последний фрагмент, основанный на текущем состоянии портлета (например, когда пользователь портала обновляет страницу или выполняется взаимодействие с другим портлетом на той же самой странице).
  • Registration Interface (не обязателен): Registration Interface позволяет WSRP-поставщику требовать от WSRP-потребителя выполнения регистрации определенного рода перед получением возможности взаимодействия со службой посредством интерфейсов Service Description и Mark-up. Посредством этого механизма поставщик может подстроить свое поведение под конкретный тип потребителя. Например, поставщик может отфильтровать предлагаемые портлеты в зависимости от конкретного потребителя. Кроме того, Registration Interface работает как механизм, позволяющий поставщику и потребителю начать диалог для обмена информацией о своих технических возможностях.
  • Portlet Management Interface (не обязателен): Portlet Management Interface предоставляет WSRP-потребителю доступ к жизненному циклу выполняющегося удаленно портлета. Используя этот интерфейс, потребитель мог бы иметь возможность настроить поведение портлета или даже уничтожить экземпляр выполняющегося удаленно портлета.

В литинге 1 приведен пример WSDL-определения службы, поддерживающей как обязательные, так и не обязательные интерфейсы.

Листинг 1. Пример WSDL-определения WSRP-службы
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:urn="urn:oasis:names:tc:wsrp:v1:bind" 
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  targetNamespace="urn:myproducer:wsdl">
  <wsdl:import namespace="urn:oasis:names:tc:wsrp:v1:bind" 
        location="http://www.oasis-open.org/committees/wsrp/
        			specifications/version1/wsrp_v1_bindings.wsdl"/>
  <wsdl:service name="WSRPService">
    <wsdl:port name="WSRPBaseService" 
    	       binding="urn:WSRP_v1_Markup_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
	              location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPServiceDescriptionService" 
               binding="urn:WSRP_v1_ServiceDescription_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
	              location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPRegistrationService" 
               binding="urn:WSRP_v1_Registration_Binding_SOAP">
	<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
		      location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPPortletManagementService" 
               binding="urn:WSRP_v1_PortletManagement_Binding_SOAP">
        <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
		      location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Обнаружение портлетов при помощи UDDI-реестра

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

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

UniversalDescription Discovery Interface (UDDI) предоставляет именно такой механизм объединения WSRP-поставщиков, предлагающих портлеты, и WSRP-потребителей, которые ищут возможность включения новых функций в свою рабочую среду. Поскольку UDDI стал стандартным средством обнаружения Web-служб, совершенно естественно, что UDDI стал также средством обнаружения портлетов. Однако обнаружение портлетов требует использования нескольких ухищрений – в конце концов портлет не является истинной Web-службой.

Как упоминалось выше, в мире WSRP существуют WSRP-поставщики, являющиеся истинными Web-службами, и WSRP-портлеты, доступ к которым может быть осуществлен только через API, предоставленный их поставщиком. Хотя WSRP-портлет можно логически представить как службу, он не является истинной Web-службой, поскольку не предоставляет API, через который потребитель мог бы вызвать его напрямую. Однако поиск портлета конечным пользователем для добавления его на страницы портала является самой обычной практикой. Пользователь не имеет понятия о WSRP-поставщике и не должен понимать суть WSRP. Но, поскольку портлет может быть доступен только через своего поставщика, и WSRP-портлет, и WSRP-поставщик должны быть опубликованы в реестре.

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

Рисунок 4. Типичный сценарий публикация-поиск-соединение в WSRP
Типичный сценарий публикация-поиск-соединение в WSRP

На рисунке 4 представлен типичный сценарий использования WSRP, который обычно состоит из следующих этапов:

  1. Провайдер разрабатывает набор портлетов, которые делает доступными, назначая WSRP-поставщика и отображая их как WSRP-портлеты. Провайдер хочет сделать эти портлеты доступными сообществу, поэтому он публикует их в центральном UDDI-каталоге. Поскольку UDDI показывает только интерфейс Web-службы, провайдер должен решить эту задачу либо через свой UI, либо через предоставляемый UDDI-сервером.
  2. Конечный пользователь ищет портлет для добавления к своему порталу. Используя предоставляемые порталом средства (либо специально написанную для этих целей программу), он выполняет поиск портлета. После обнаружения желаемого портлета пользователь легко добавляет новое приложение к одной из своих страниц портала. В качестве альтернативы администратор портала может найти портлеты в UDDI-реестре и сделать их доступными для пользователей, добавив во внутренний реестр портала.
  3. Теперь, после открытия страницы, в которую пользователь добавил новый портлет, он увидит на этой странице выполняющийся удаленно портлет. За кулисами портал выполняет запрос Web-сервиса к удаленному поставщику, а поставщик возвращает фрагмент на языке разметки страниц, который портал интегрирует в отображаемую страницу. Конечный пользователь полностью избавлен от деталей WSRP: все что он знает – это то, что может легко и просто интегрировать новое приложение в свой портал.

Заключение

Эта статья знакомит с Web Services for Remote Portlets (WSRP) и показывает, как можно использовать мощь WSRP для легкой интеграции нового приложения в существующий портал. Появление WSRP означает, что вы больше не ограничены повторным использованием только встроенных, работающих в фоновом режиме (back-end) служб, но можете также использовать ориентированные на представление службы. Представьте, как может быть применен WSRP для облегчения разработки целой сети ориентированных на представление Web-служб. Пользователи портала могут легко обнаружить и использовать любое количество этих служб. У разработчиков нет необходимости в создании специализированных адаптеров, написании клиентского кода или затратах времени для локального развертывания портлетов. Добавление портлетов к рабочей среде портала представляет собой несколько нажатий кнопки мыши.

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, XML
ArticleID=96586
ArticleTitle=Введение в Web Services for Remote Portlets
publish-date=04152005