Создание взаимодействующих компонентов для IBM Lotus Expeditor Property Broker

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Боб Балфе, старший инженер-программист и руководитель проекта, Lotus

04.04.2007

Познакомьтесь с IBM Lotus Expeditor Property Broker и узнайте, как можно создать компонент, принимающий участие в декларативном взаимодействии, предлагаемом брокером. Мы покажем, как подключить компоненты декларативно с использованием точек расширения IBM WebSphere Portal Wiring Tool и Property Broker API.

В данной статье вы познакомитесь с IBM Lotus Expeditor Property Broker. Мы рассмотрим, как создать компонент, и как он может участвовать в декларативном взаимодействии между полностью разделенными (decoupled) компонентами. Этими компонентами могут быть любые определенные Java-объекты, которые корректно регистрируют себя при помощи Property Broker как идентифицируемые свойства или действия. Затем можно декларативно объединить компоненты, используя точки расширения IBM WebSphere Portal Wiring Tool или Property Broker API.

Данная статья предназначена для разработчиков приложений, хорошо знакомых с Lotus Expeditor (прежде назывался IBM WebSphere Everyplace Deployment). В ней предполагается, что вы разбираетесь в таких терминах как действие, свойство и т.д.

Сравнение IBM Lotus Expeditor Broker и IBM WebSphere Portal Property Broker

По возможностям Lotus Expeditor Property Broker очень похож на WebSphere Portal Property Broker. При использовании в контексте составных приложений XML из WebSphere Portal служит средством связи и взаимодействия разделенных компонентов. Инфраструктура составного приложения (composite application infrastructure - CAI) заботится о регистрации и активизации взаимосвязей. Если говорить о компоненте, разработанном для использования в CAI, то главными задачами разработчика являются публикация изменений свойств и реакция на изменения свойств. Что же касается компонентов, созданных для работы вне CAI, то необходимо позаботиться о регистрации взаимосвязей, активизации и деактивизации.

При существующей сложности многооконной и многозадачной среды, предоставляемой платформой Eclipse и Lotus Expeditor, самым существенным отличием Property Broker от его сородича WebSphere Portal Broker является способность расширять интегрированные среды дополнительных действий. WebSphere Portal разрешает взаимодействие между портлетами различного типа; однако клиентский Property Broker разрешает создавать новые расширения брокера, используя точку расширения Eclipse. Lotus Expeditor поставляется с тремя расширениями обработчиков действий, каждое из которых может использоваться для совместимости с существующим кодом. Тремя готовыми, поставляемыми с Lotus Expeditor обработчиками действий являются:

• Eclipse Core Commands
• SWT-действия (Standard Widget Toolkit)
• AWT-компоненты (Abstract Windows Toolkit)

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

В начало

Корректная разработка пользовательских компонентов

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

Вот несколько советов по дизайну компонентов:

1. Объявляйте виды и действия в одном и том же пакете (для ясности). Таким образом, даже если классы различны по природе, они связаны в структуре одного пакета. Одним из способов является использование субпакета (sub-package) в Actions, в котором размещены все классы действий.
2. Для простоты нужно предоставлять один WSDL-файл (Web Services Description Library) для каждого действия. Хотя Property Broker разрешает определять несколько действий в одном WSDL-файле, это делать не рекомендуется, если действие не выступает в качестве группового контейнера для других действий.
3. Использование Property Broker вместе с CAI - самый простой метод. Если вы намерены использовать Property Broker и действия вне этой интегрированной среды, то нужно предоставить код, который должным образом разрешает и запрещает действия и взаимосвязи. Необходимо также предоставить код, регистрирующий взаимосвязи; если XML составного приложения используется из WebSphere Portal, взаимосвязи определяются в XML.
4. Помните о том, что пространства имен свойств имеют ограничение - свойство должно быть уникально в данном пространстве имен. Нельзя иметь свойство с именем URL в одном компоненте и свойство с именем URL в другом компоненте, разделяющем то же самое пространство имен. Возможно, понадобится предварить имя свойства различимым идентификатором вида или действия для обеспечения уникальности.
5. Если действие выполняет обновление UI-компонента, убедитесь в том, что находитесь в потоке UI при выполнении вызова для обновления метки или управляющего UI-элемента. Шаблоны это предусматривают и предоставляют соответствующий код.

В начало

Пример приложения

Пример приложения, демонстрирующий два развязанных компонента, на базовом уровне показывает, как создаются оба компонента, а затем объединяются при помощи WebSphere Portal. Приложение имеет два компонента: вид URL Selector слева и вид Managed Browser справа (см. рисунок 2). Оба вида были разработаны в своих собственных подключаемых модулях и не имеют двоичных зависимостей друг от друга.

Selector - это простой вид со списком адресов URL, которые может выбрать пользователь. Этот вид публикует свойство под названием URL From Tree с типом URL. Browser - это SWT-вид с элементом управления Embedded Browser. Этот вид регистрирует действие loadURL, которое принимает один входной параметр URLIn.

При публикации видом Selector свойство проходит через Property Broker в обработчик действий SWT и в действие в подключаемом модуле ManagedBrowser. Это действие затем использует класс SWTHelper для поиска экземпляра view и для вызова метода loadURL() объекта view.

В начало

Обработчики действий

Чтобы понять архитектуру Property Broker, необходимо, прежде всего, понять, что такое обработчик действия (action handler). Фундаментальной причиной существования точки расширения обработчика действия является разрешение существующим системам, основанным на работе с событиями или сообщениями, внедрять действия в модель декларативного брокера. Как отмечалось выше, Lotus Expeditor поставляется с тремя обработчиками действий. Необходимо использовать соответствующие реализации действий на основе требований обработчиков действий. В конечном итоге, действие вызывается одним из этих обработчиков. Брокер передает изменение свойства в зарегистрированный обработчик вашего типа объекта action. В таблице 1 перечислены три доступных обработчика.

Самое важное для понимания – это информация в столбце "Зависимости" таблицы. Для автономных действий (подключаемый модуль или код, которые не могут иметь UI-зависимости) используется интерфейс org.eclipse.core.commands.IHandler. Если компонент является графическим, например, SWT-вид, необходимо реализовывать интерфейс org.eclipse.core.commands.IHandler, но указывать тип SWT_ACTION при создании действия. Обработчик SWT-действия устраняет необходимость заботиться о разрешении и запрещении взаимосвязей на уровне страниц. Все взаимосвязи, определенные в XML составного приложения, корректно разрешаются или запрещаются при показе или скрытии перспектив соответственно.

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

В начало

Создание действий в пользовательских компонентах

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

Начнем с создания расширения точки расширения PropertyBrokerDefinitions. Для создания этой точки расширения необходима зависимость с пакетом com.ibm.rcp.propertybroker. Это расширение правильно регистрирует действие с его входными и выходными свойствами.

Для быстрого начала работы можно использовать один из шаблонов, поставляемых с Lotus Expeditor Toolkit. Шаблон Property Broker Definitions создает расширение, WSDL-файл и Java-класс action. Существуют два шаблона: один для базового Eclipse-действия, а второй - для SWT-действия (см. рисунок 4).

Шаблон отображает экран, в котором заполняются названия входных и выходных свойств вместе с пространством имен, в котором вы хотите их объявить (см. рисунок 5). Шаблоны должны рассматриваться как отправные точки, поскольку они создают действия только с одним входным и одним выходным свойством. Всегда можно вручную изменить WSDL-файл и включить дополнительные выходные параметры.

ПРИМЕЧАНИЕ: В настоящее время Property Broker поддерживает только одно входное свойство.

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

ПРИМЕЧАНИЕ: Все это можно изменить напрямую в WSDL и в коде действия после его генерирования.

Мы создали класс действия, являющийся входной точкой при изменении свойства.

На рисунке 6 показана интегрированная среда разработки Eclipse (IDE) и артефакты, создаваемые шаблоном из предоставленной информации. Позиция 1 на рисунке - это Java-файл действия для базовой команды Eclipse или для SWT-действия; позиция 2 - это полнофункциональный WSDL-файл из введенной выше информации; позиция 3 - это точка расширения; позиция 4 - связь со сгенерированным WSDL.

Наконец, когда Property Broker обрабатывает расширение PropertyBrokerDefinitions, он регистрирует свойства с ID подключаемого модуля в качестве ID владельца. Важно понимать это, поскольку владелец в Property Broker должен иметь в себе уникальные компоненты. Один владелец может иметь только уникальные имена свойств и действий.

В начало

Использование SWT-действий с Property Broker

Давайте рассмотрим, как SWT-компоненты, являющиеся видами, используются в интегрированной среде Property Broker. Во-первых, нужно понимать, что код действия не связан непосредственно с каким-либо конкретным видом или экземпляром вида. Однако возможно обновить конкретный экземпляр вида комбинацией CAI и данными, переданными в действие. К сожалению, это не легко сделать в SWT-действиях, но доступны вспомогательные API.

Когда действие вызывается в методе execute(), необходимо вызвать пару вспомогательных функций для обновления конкретного экземпляра вида (если это то, для чего предназначено действие). Пример кода выглядит приблизительно так, как показано в листинге 1.

public Object execute(ExecutionEvent event) throws ExecutionException {

  final Object eventTrigger = event.getTrigger();
	
  if (eventTrigger instanceof PropertyChangeEvent){
	final PropertyChangeEvent pce = (PropertyChangeEvent)eventTrigger;
			
	final PropertyValue value = pce.getPropertyValue();
			
	Display.getDefault().asyncExec(new Runnable() {
		public void run(){

		Wire def = pce.getWireDefinition();
					
		ViewPart view = SWTHelper.locateView(def.getTargetEntityId());
					
		}
	});
  }
  return null;
}

Обратите внимание на строки, выделенные жирным шрифтом. Класс SWTHelper имеет статические методы, помогающие идентифицировать конкретный экземпляр вида, с которым вы работаете. ID вида содержится в объекте определения связи, который содержится в PropertyChangeEvent. В определении связи можно ссылаться на исходный вид и на целевой вид связи. CAI гарантирует вызов действия с корректной информацией. Вызов locateView() возвращает IViewPart, являющийся экземпляром целевого вида. Необходимо выполнить операцию instanceOf для гарантии того, что это именно тот вид, который вы ищете, а затем выполнить операцию приведения типа к соответствующему классу вида.

В начало

Интегрирование пользовательского компонента с WebSphere Portal CAI

Следующий шаг - регистрация компонента в WebSphere Portal для интегрирования его в CAI. Первичным артефактом является WSDL-файл, созданный для расширения действия. Этот же WSDL-файл должен использоваться в портлете, определенном в WebSphere Portal. Причина этого состоит в том, что портлет регистрирует свойства и действия с использованием WebSphere Portal Property Broker и позволяет портлету соединяться с другими портлетами (для начала вспомните, что все компоненты в WebSphere Portal должны быть портлетами). При использовании Eclipse-видов в качестве систем времени исполнения необходимо лишь зарегистрировать портлет с WebSphere Portal, для того чтобы свойства и действия могли быть зарегистрированы для компонента. В сущности, портлет - это место-заместитель на экране, в которое ваш компонент будет отображать содержимое на клиенте.

Для данного упражнения мы создадим пример портлета в IBM Rational Application Developer и присоединим к нему WSDL-файл. Код портлета ничего не должен делать, поскольку мы не используем портлет для системы времени исполнения. Портлет конфигурируется так, чтобы указать клиентской CAI использовать наш SWT-вид вместо портлета.

После создания портлета добавьте WSDL к нему так же, как сделали бы при создании взаимодействующего портлета. Измените файл portlet.xml и укажите в нем месторасположение в WAR-файле, куда был помещен ваш WSDL-файл (см. рисунок 7).

ПРИМЧАНИЕ: Название портлета должно походить (для ясности) на название Eclipse-вида. При помещении портлета на страницу больший смысл имеет близкое соответствие его имени с именем SWT-вида.

На рисунке 7 можно увидеть, что необходимой настройкой портлета является com.ibm.portal.propertybroker.wsdllocation. Для каждого имеющегося у вас портлета и WSDL-файла нужно добавить эту настройку в portlet.xml.

Следующий шаг - экспорт WAR-файла из Rational Application Developer, а затем, используя программу Portal Admin в Portlet Management, импорт его в WebSphere Portal (см. рисунок 8).

Можно спакетировать портлеты, представляющие виды, в один WAR-файл. Также рекомендуется, чтобы настройки WAR-файла и подключаемого модуля Eclipse были как можно более близкими.

Затем поместите портлеты на страницу (см. рисунок 9) и измените их настройки в закладке Rich Client, которая устанавливается тогда, когда ваш администратор устанавливает Network Client Installer (NCI) на WebSphere Portal.

После размещения портлетов на экране можно изменить настройки экземпляров портлетов (см. рисунок 10).

Закладка Rich Client помогает упростить настройку портлета. Код устанавливает настройку com.ibm.rcp.viewId в текст, который вы помещаете в поле id Eclipse-вида. Это должен быть первичный ID вида вашего SWT-компонента. Когда CAI создает перспективу и регистрирует вид, ID портлета является вторичным ID вида.

После настройки компонентов и вставки их в страницу можно соединить совместимые свойства и действия при помощи программы Portal Wiring Tool, расположенной в закладке Wires. На рисунке 11 показан портлет URLSelector, соединенный с портлетом Managed Browser.

В начало

Развертывание компонента для предоставления услуг

Для распространения компонента как части составного приложения из WebSphere Portal необходимо развернуть подключаемые модули компонента на HTTP-сервере и направить компоненты на этот сервер. Для этого укажите URL сайта обновления Eclipse в закладке Rich Client редактора предпочтений портлета.

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

На рисунке 12 показаны URL и требование, указанные на закладке Rich Client для портлета. Обратите внимание на то, что указывается ID функциональности, версия и правило соответствия вместе с URL, из которого функциональность извлекается.

Указывая функциональность в предпочтениях портлета, вы указываете CAI загрузить эту функциональность до запуска приложения. Следовательно, функциональности загружаются, устанавливаются и активизируются до загрузки экрана.

В начало

Отладка с использованием OSGi-консоли

Запуская Lotus Expeditor или платформу Eclipse с ключом -console, можно вызвать Property Broker некоторыми командами консоли. Эти команды предназначены только для отладки. Поскольку декларативные системы могут быть довольно сложными по природе, эти команды должны помочь выяснить, какие компоненты, если они есть, вызываются Property Broker.

Property Broker имеет ряд команд OSGi-консоли (Open Service Gateway initiative), которые могут быть выполнены в целях отладки и тестирования. Эти команды присутствуют только при запуске платформы командой console, и их список можно отобразить при помощи команды help. Ниже приведен текущий список команд, поддерживаемых Property Broker (обратите внимание на то, что все команды начинаются с pb):

---Property Broker Commands---
	pbsh a - Show all Actions
	pbsh aa - Show all Active Actions
	pbsh p - Show all properties by owner
	pbsh p <owner> - Show all properties for this owner (string owners only)
	pbsh w - Show all enabled wires
	pbsh aw - Show all wires
	pbsh ns - Show registered name spaces
	pbt <Property> - Trace the path for the specified property
	pbut <Property> - UnTrace the specified property, removes the trace
	pblt - Show a list of the currently traced Properties

Как отмечалось выше, владельцем действий и свойств по умолчанию является ID подключаемого модуля, в котором создается расширение. Для связей (при использовании в CAI) их владельцем является ID перспективы. Когда CAI регистрирует связи, он автоматически назначает ID перспективы в качестве владельца связи. При переключении перспектив CAI автоматически разрешает и запрещает связи соответствующим образом. При ручной регистрации связей (с использованием API или Extension Point) за разрешение, запрещение и отмену регистрации этих связей несете ответственность вы.

В начало

Советы по отладке

Ниже перечислены некоторые возможные проблемы и советы по их устранению:

• Трассировка свойства
  Если не известно, почему компонент не принимает изменения свойства, то можно выполнить трассировку этого свойства при помощи команды pbt Property Broker. Эта команда отображает отладочную информацию на консоли и в журнале регистрации, трассируя путь измененного свойства. Если никакая информация не отображается, возможно, неправильно указано имя свойства или исходный компонент не опубликовал свойство, например:
  
  osgi> pbt mypropery
osgi> pbt “my property with spaces”
  
• Связи не работают
  Если есть подозрения на то, что компонент не работает или не принимает изменений свойств, проверьте, разрешены ли связи и действия. Для отображения всех активных связей можно использовать команду pbsh w, а для отображения всех активных действий - команду pbsh aa.
  
• Регистрация WSDL
  Для проверки корректной регистрации WSDL-файла в Property Broker используйте базовые команды show для свойств и действий. Команды pbsh p и pbsh p <owner> отображают список всех зарегистрированных свойств. Для получения списка всех зарегистрированных действий можно использовать команду pbsh a.

Отладка топологий WebSphere Portal

Вы можете иметь много приложений WebSphere Portal, а в этих приложениях может использоваться много страниц, на которых имеется много компонентов. Для получения XML составного приложения из WebSphere Portal и динамического создания перспектив, их схем и видов для Eclipse используется менеджер топологии на стороне клиента. Обработчик топологии предоставляет также модель данных для перспектив и видов и связывает Eclipse-действия со страницами.

Ниже приведен список OSGi-команд, доступных для отладки (вспомните, что этот список можно отобразить при помощи выполнения команды help OSGi-консоли):

---Topology Handler UI Commands---
thuish desc - Show all Perspective Descriptors
thuish del <perspective id> - Delete a Perspective Descriptor
thuish lp Show all Launcher Item IDs
thuish cd Show Current Perspective Descriptor
thuish ea Show Current Enabled Activities
thuish a <activity id> Show Activity State


---Topology Handler Commands---
thsh n - Show all navigation elements
thsh p - Show all Pages
thsh l - Show all Labels
thsh f - Show all topology files
thsh apps - Show all application GUIDs
thsh e <namespace> - Show all registered extensions under the given namespace
thsh dp - Show all dirty pages
thsh nattr <navigation id> - Show all navigation preferences

В начало

Заключение

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

Ресурсы

• Оригинал статьи "Creating collaborative components for IBM Lotus Expeditor Property Broker".
  
  
• Страница developerWorks Lotus Expeditor.
  
  
• Статья developerWorks Lotus "Разработка OSGi-службы как Web-службы в IBM Lotus Expeditor".
  
  
• Статья developerWorks Lotus "Создание и развертывание простого Web Services Resource в IBM Lotus Expeditor".
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Блог developerWorks Composite Applications.

Об авторе

		Боб Балфе (Bob Balfe) работает старшим инженером-программистом в IBM и архитектором клиентского приложения, управляемого порталом, в группе WebSphere Everyplace Deployment.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало