Компоненты Lotus Expeditor

В статье «Middleware для организации современного рабочего места», опубликованной во втором номере журнала за этот год, говорилось об организации и структуре Lotus Expeditor. Здесь более детально будут рассмотрены компоненты Expeditor.

Напомним, что для создания приложений с использованием Expeditor (помимо умения пользоваться конкретными программными инструментами, входящими в состав WebSphere Portal, Lotus Expeditor и др.) в общем случае нужно (помимо практических знаний Java):

Понятие компонентов в Expeditor

При использовании Expeditor термин «компонент» понимается в достаточно широком смысле. Компонент – это фрагмент кода, xml-объявлений и прочих ресурсов, которые составляют одну сущность, обычно хранятся в виде архива или сборки и используются неким стандартным (на уровне Expeditor – речь не об открытых стандартах) образом. Например, компоненты Expeditor не обязательно имеют интерфейсы пользователя. Прекрасным примером таких компонентов являются сборки (bundles) OSGi, которые в терминах Eclipse известны как плагины, которые, в свою очередь, могут объединяться в сборки более высокого уровня (features).

«Классические» компоненты, исполняемые в средах, построенных на основе Eclipse (именно к таким платформам относится Expeditor) написаны на Java с использованием Plugin Development API и SWT или SWT/JFace. Это, разумеется, исключает использование Web-компонентов, включая портлеты, которые для работы требуют для наличия собственных контейнеров. Поскольку Expeditor является интеграционной платформой, он не может игнорировать такие распространенные компоненты и приложения на их основе. Это означает, что в состав Expeditor должна входить стандартная реализация Web-контейнера с поддержкой сервлетов и JSP, а также стандартных портлетов, т.е. портлетов, соответствующих спецификации JSR168. Другими словами, Expeditor обладает стандартными возможностями сервера Web-приложений; не забывайте, что речь идет о клиентской платформе!

Развернутые компоненты должны взаимодействовать универсальным образом – вне зависимости от их вида, реализации и их разработчика. Требуемая универсальность достигается за счет использования уже традиционного механизма организации взаимодействия слабосвязанных фрагментов систем – Web-сервисов. Взаимодействие компонентов – большая и важная самостоятельная тема, и она будет рассмотрена отдельно.

RCP компоненты

В предыдущей статье уже говорилось об RCP-компонентах. На самом деле, применительно к практическим вопросам работы с Expeditor, наиболее важными характеристиками RCP-компонентов являются следующие:

Портлеты

Приложения на основе портлетов являются по своей природе наиболее естественной реализацией архитектуры SOA, которая (с точки зрения визуального представления информации) сводится к единообразному, интегрированному и «управляемому» отображению данных, полученных от разных источников и сервисов. Привычной реализацией портала (portal view) является использование контейнеров портлетов (которые, как правило, служат одним из сервисов стандартных серверов приложений). Примером такого портала, раз уж разговор идет о продуктах компании IBM, сервер WebSphere Portal. Для доступа к порталу обычно используется браузер.

Тем не менее, Expeditor позволяет создать портальное приложение и на основе RCP-компонентов на платформе Expeditor.

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

Важно подчеркнуть, что Lotus Expeditor поддерживает только портлеты, соответствующие JSR 168, хотя, например, WebSphere Portal (с которым обычно тесно взаимодействует Expeditor) способен работать также с нестандартным IBM Portlet API.

Для разработки и отладки клиентских портлет-приложений на платформе OSGi можно использовать различные средства. Одним из таких программных средств является Expeditor Tooilkit, который также способен выполнять конвертацию стандартных J2EE-приложений, использующих портлеты, в приложения, выполняемые под управлением Expeditor. Пожалуй, наиболее развитыми возможностями для разработки, отладки, развертывания и тестирования таких приложений обладают продукты семейства IBM Rational Software Development.

С точки зрения разработчика, нет существенной разницы между портальными клиентскими и портальными серверными приложениями. Единственное отличие заключается в том, что среда Lotus Expeditor требует наличия дополнительного xml-дескриптора – файла plugin.xml.

Этот дескриптор обязательно должен включать в себя точку расширения Eclipse (extension point) com.ibm.eswe.workbench.WctWebApplication:

<extension id="..."point="com.ibm.eswe.workbench.WctWebApplication">
  <WEBApplication DisplayName="...">
  <WebApplicationUrl local="true" secured="false"
                     url="/.../default/ver=1.0/mode=view"/>
  <BrowserConfiguration showAddressbar="true" showBookmark="false"
    showHistory="true" showHome="false" showPrint="false"
    showToolbar="true"/>
  </WEBApplication>
</extension>

Теги дескриптора задают следующие значения:

Еще одной очень важной точкой расширения является com.ibm.pvc.webcontainer.application. Она используется для задания портлетов в данном плагине и их режимов. Ниже приведен простой пример:

<extension point="com.ibm.pvc.webcontainer.application">
  <contextRoot>...</contextRoot>
  <contentLocation>WebContent</contentLocation>
  <actionClass>javax.portlet.PortletSessionUtil</actionClass>
  <portletOptions>
    <portlet>
      <portlet-name>...</portlet-name>
      <supports>
        <portlet-mode>view</portlet-mode>
      </supports>
    </portlet>
  </portletOptions>
</extension>

Web-компоненты на стороне клиента

Платформа Lotus Expeditor поддерживает (применительно к Web-компонентным моделям ) стандарты Servlet v2.4 и JSP™ v2.0, а также Servlet v2.3 и vJSP 1.2. Web-приложения, создаваемые для выполнения под управлением Lotus Expeditor, называются Client Services Web-приложениями.

Для того, чтобы сохранить ясную и понятную терминологию, применительно к Expeditor было изменено название таких Web-приложений: поскольку компоненты OSGi/Expeditor называются «сборками» (bundles), то Web-приложения для этой платформы называются Web Application Bundle (WAB).

Главное отличие между WAB и WAR Web-приложениями (предназначенными, например, для развертывания на WebSphere Application Server) состоит в том, что WAB-файлы должны соответствовать всем требованиям спецификации OSGi. Обычно разработчику не приходится об этом беспокоиться, поскольку современные средства разработки, в том числе Expeditor Toolkit, обеспечивают это автоматически.

Сходство между WAB и WAR настолько велико, что WAR-приложение, созданное как динамический Web-проект, можно протестировать на платформе Expeditor. Входящая в состав Expeditor Toolkit утилита WAB позволяет выполнить автоматическую трансформацию существующих WAR-файлов в WAB-файлы для последующего запуска под управлением Expeditor.

Упомянутый ранее xml-дескриптор plugin.xml очень похож на свой аналог для портлетов, он тоже должен включать в себя точку расширения com.ibm.eswe.workbench.WctWebApplication:

<extension id="..." 
           point="com.ibm.eswe.workbench.WctWebApplication">
  <WEBApplication DisplayName="...">
    <WebApplicationUrl local="true"
                       secured="false"
                       url="…"/>
    <BrowserConfiguration showAddressbar="false"
                          showBookmark="false"
                          showHistory="false"
                          showHome="false"
                          showPrint="false"
                          showToolbar="false"/>
  </WEBApplication>
</extension>

WebApplicationURL, как и следовало ожидать, задает корневой Web-контекст. Здесь вы можете также указать имя сервлета и/или JSP-документа. Если имя ресурса не указано, то Lotus Expeditor будет использовать имя страницы по умолчанию, заданное в теге <welcome-file-list> в дескрипторе web.xml.

Остальные параметры имеют те же значения, что и для портлетов.

Как и в случае с портлетами, в обязательный для платформы Expeditor дескриптор plugin.xml нужно включить точку расширения (com.ibm.pvc.webcontainner.application), в которой описываются Web-компоненты плагина:

<extension point="com.ibm.pvc.webcontainer.application">
  <contextRoot>...</contextRoot>
  <contentLocation>WebContent</contentLocation>
</extension>

Удаленные (remote) портлеты

Сравнительно недавно принятая спецификация Web Services for Remote Portlets (WSRP) чрезвычайно облегчает включение представления из удаленных портлетов, различных источников данных и удаленных порталов, практически не требуя дополнительного кодирования – только за счет средств администрирования. WSRP использует термин «продюсер» (producer) для обозначения портала, предоставляющего доступ к одному или нескольким своим портлетам как сервисам WSRP, термин «консьюмер» (consumer) для портала, который обращается к продюсеру и интегрирует содержимое его портлетов в приложении (в нашем случае – в приложении под управлением Expeditor). Портлет, который доступен как WSRP-сервис, называется «удаленным портлетом».

На приведенном ниже рисунке показана общая схема взаимодействия портлетов составного приложения с использованием WSRP.

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

Стандарт WSRP определяет набор интерфейсов, которые реализованы на стороне продюсера для доступа со стороны консьюмера. Как и следовало ожидать, эти интерфейсы описаны на языке WSDL. Lotus Expeditor содержит стандартный набор «служебных» портлетов. Например, в качестве консьюмера выступает компонент Portlet Viewer WSRP.

Ниже приведен пример простого WSDL-файла, иллюстрирующий вышесказанное.

Под <portal> понимается доменное имя портального сервера, на котором выполняется портлет. Расположение данного WSDL-файла (URL) указывается в описании точки расширения для плагина, как было показано ранее.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:oasis:names:tc:wsrp:v1:wsdl"
                  xmlns:bind="urn:oasis:names:tc:wsrp:v1:bind"
                  xmlns="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
  <import namespace="urn:oasis:names:tc:wsrp:v1:bind"
          location="wsrp_v1_bindings.wsdl"/>
  <wsdl:service name="WSRPService">
    <wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP"
               name="WSRPBaseService">
      <soap:address location="http://<portal>/wsrp/WSRPBaseService"/>
    </wsdl:port>
    <wsdl:port binding="bind:WSRP_v1_ServiceDescription_Binding_SOAP"
               name="WSRPServiceDescriptionService">
      <soap:address 
        location="http://<portal>/wsrp/WSRPServiceDescriptionService"/>
</wsdl:port>
    <wsdl:port binding="bind:WSRP_v1_PortletManagement_Binding_SOAP"
               name="WSRPPortletManagementService">
      <soap:address 
        location="http://<portal>/wsrp/WSRPPortletManagementService"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Для отображения информации из удаленного портлета Lotus Expeditor содержит специальный компонент – portlet viewer. При работе с композитными приложениями удаленный портлет может быть развернут как часть этого приложения. Экземпляр WSRP portlet viewer’а определяется и создается с использованием точки расширения com.ibm.rcp.portletviewer.WsrpPortlets, например:

<extension point="com.ibm.rcp.portletviewer.WsrpPortlets">
  <wsrpData entityId="..."
    wsrp_wsdl="http://<portal>/... .wsdl"
    handle="5_8GUNUKG100CKC02EESU1TF1OV0" need_client_clone="true"
    isSecured="false">
  </wsrpData>
</extension>

Другие компоненты для композитных приложений

Компоненты, о которых кратко было рассказано выше – это только часть компонентов, которые могут быть использованы при создании приложений для платформы Expeditor. Все они написаны на Java, все выполняются под управлением виртуальной машины Java, входящей в состав Lotus Expeditor. Возможны и другие виды компонентов, которые создаются с помощью иных программных средств и требуют для своей работы специальных собственных операционных сред. IBM использует для обозначения инструментов для создания таких компонентов термины «Построитель» (Builder) или «Дизайнер» (Designer).

К таким компонентам относятся, например, компоненты Lotus Notes 8 (и, соответственно, программные инструменты для создания и развертывания, входящие в состав Lotus Notes/Domino, например, Lotus Component Designer). Другим чрезвычайно полезным и удобным инструментом во многих случаях может оказаться WebSphere Portlet Factory Designer.

Концепция «управляемых» (managed) приложений

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

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

В левой части рисунка в прямоугольниках изображены компоненты различных видов – RCP-компоненты, портлеты, удаленные портлеты. В правой – соответствующие им плагины (т.е. jar-файлы) и features.

Основными частями любого составного управляемого сервером приложения являются:

Развертывание приложения на стороне клиента

Работа с управляемыми серверами составными приложениями подразумевает, что при первом обращении клиента к такому приложению его (это приложение) необходимо установить на стороне клиента. Это также означает, что те компоненты устанавливаемого приложения, которые не были установлены как часть Lotus Expeditor, также должны быть доставлены на сторону клиента и быть доступными для «локальной» работы.

Выполнение этих функций берет на себя специально для этого предназначенный программный слой в составе Eclipse – реализация Open Service Gateway initiative (OSGi). Задача Lotus Expeditor при этом сводится к тому, чтобы получать информацию о необходимых features и о том, где эти необходимые features расположены. Затем эта информация передается на уровень OSGi, который добывает необходимые инсталляционные файлы и устанавливает нужные features и их соответствующие плагины в нужном порядке.

В терминах Eclipse «репозитарий», где хранятся необходимые для доставки на сторону клиента и последующей установки плагины, называется «сайтом обновлений» (update site). Сайты обновлений давно (начиная с версии 3.0) используются для расширения возможностей и обновлений самого Eclipse. Обычно сайт обновлений – это очень простой репозитарий файлов, для доступа к которым могут использоваться как средства доступа как к локальным файлам, так и удаленные протоколы, такие, как HTTP. «Корневой каталог» репозитария содержит файл описания сайта обновлений – site.xml.

Содержимое файла site.xml представляет собой, по сути, просто список features и плагинов:

<?xml version="1.0" encoding="UTF-8"?>
<site>
  <feature
    url="features/… .feature_one_1.0.0.jar"
    id="…" version="1.0.0"/>
  <feature
    url="features/….feature_two_1.0.0.jar"
    id="…" version="1.0.0"/>
...
</site>

Определение и размещение компонентов

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

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

Ситуация становится намного сложнее при создании приложений для Lotus Expeditor, так как он способен управлять различными типами компонентов, а не только портлетами. Следовательно, при запуске составного приложения на стороне клиента под управлением Expeditor нужно знать, какие компоненты должны выполняться тогда, когда на определенной стороне выполняется определенный портлет.

Для размещения компонентов различных видов на страницах обычно используются средства администрирования порталом.

Размещение Eclipse-компонентов

Совершенно очевидно, что плагины Eclipse, как и сборки OSGi, не могут быть ни установлены, ни запущены на стандартном сервере портлетов. Тем не менее, такую работу необходимо обеспечить в случае развертывания на сервере управляемого композитного приложения, содержащего RCP-компоненты.

Для решения данной проблемы используется традиционный подход – создается «обертка» в виде портлетов для RCP-компонентов, устанавливаемых на стороне сервера. После установки Lotus Expeditor NCI (Network Client Installer) на стороне сервера создается прокси-портлет – Rich Client View Placeholder, который доступен и понятен для WebSphere Portal. Именно этот портлет размещается потом на странице администратором приложения, после чего этот портлет играет роль «рамки» для представления (view) Eclipse.

Для задания установок (какое представление нужно использовать, какие features используются в плагинах для этого представления, какой размер должно иметь и т.д.) используется еще один вспомогательный портлет – портлет Rich Client Layout Administration.

При редактировании портлета и задании его свойств администратор попадает в графический редактор, где, используя различные закладки, можно менять различные параметры портлетов и компонентов. Закладка rich client на странице layout обеспечивает доступ к портлету администратора – Rich Client Layout Administration. На этой закладке администратор задает глобальные опции для страницы и соответствующие опции для каждого из компонентов, размещаемого на данной странице.

Lotus Expeditor должен иметь возможность загрузить все необходимые features и плагины. В принципе, можно поместить все нужные для работы плагины в единственную feature. Тем не менее, далеко не всегда это удобно, и во многих случаях разработчики создают несколько features.

Опции позволяют задать имена и номера версий для features.

Помимо имени и номера версии, администратор может задать правила соответствия (выпадающий список с меткой «matching rule») при выборе доступной версии. Правило соответствия может быть одним из следующих:

И, наконец, необходимо задать URL сайта обновлений (поле ввода с меткой «Provisioning URL»), с которого происходит загрузка features.

Размещение портлетов

Размещение портлетов выполняется достаточно просто. Например, WebSphere Portal содержит специальные программные инструменты, с помощью которых администратор размещает портлеты на странице. Конечно, для этого портлеты должны быть доступны серверу портлетов, т.е. их необходимо установить в WebSphere Portal или другом сервере. Портлеты, как обычно, создаются в виде WAR-архивов, и все происходит так же, как при работе с портлетами вне всякой связи с наличием или отсутствием Expeditor. Expeditor’у необходимо только предоставить информацию о том, как получить доступ к feature, содержащему портлет. Для этого используется портлет админстратора Rich Client Layout Administration. Кроме того, необходимо задать корневой контекст приложения (он должен быть задан в xml-дескрипторе plugin.xml). Ниже приведен пример соответствующего фрагмента файла plugin.xml:

<extension point="com.ibm.pvc.webcontainer.application">
  <contextRoot>...</contextRoot>
  <contentLocation>WebContent</contentLocation>
  <actionClass>javax.portlet.PortletSessionUtil</actionClass>
  <portletOptions>
    <portlet>
      <portlet-name>...</portlet-name>
      <supports>
        <portlet-mode>view</portlet-mode>
      </supports>
    </portlet>
  </portletOptions>
</extension>

Размещение удаленных портлетов

В случае использования удаленного WSRP-портлета в качестве компонента, размещаемого на странице, необходимо использовать прокси-портлет WSRP Rich Client Viewer Enablement Portlet, который, как и вспомогательный портлет Rich Client View Placeholder, становится доступным на стороне сервера после установки средств Lotus Expeditor NCI. Это портлет может быть использован много раз в различных частях приложения, для каждого случая нужно создать новый его экземпляр с нужным набором свойств. Этот портлет исходно выглядит так:

При задании конфигурации необходимо задать полное доменное имя нужного WebSphere Portal’а. Это имя должно содержать в конце контекст /wps/wsdl/, например:

После нажатия на кнопку OK администратор может выбрать нужный WSRP-портлет из списка доступных портлетов.

Размещение Web-приложений как компонентов

Наконец, в качестве компонента составного приложения можно использовать созданное ранее Web-приложение. Здесь не требуется ни дополнительного кодирования, ни сложных действия администратора. Web-приложение нужно упаковать в виде feature, затем задать место расположения «окна» браузера и URL самого Web-приложения.

Как и в случае использования RCP-компонента, для Web-приложения нужно использовать вспомогательный прокси-портлет – портлет Rich Client Managed Browser Administration, который становится доступным после установки Lotus Expeditor NCI. Можно создать несколько копий этого портлета. Администратор помещает этот портлет на нужную страницу, получает доступ к списку доступных опций и задает их значения. Смысл большинства опций очевиден по их названию.

...
<plugin>
<extension point="com.ibm.pvc.webcontainer.application">
  <contextRoot>...</contextRoot>
  <contentLocation>WebContent</contentLocation>
</extension>
...

Следующей – после размещение компонентов на страницах – стадией разработки приложения является организация взаимодействия компонентов.

Взаимодействие компонентов

В основу организации взаимодействия компонентов Expeditor положен принцип разделения собственно кода компонентов, типов передаваемых параметров (в настоящий момент здесь все просто – пока Expeditor способен передавать только строки Java) и описания передаваемых между компонентами сообщений. Для описания взаимодействия используется WSDL. При использовании программных инструментов, входящих в состав Expeditor, или продуктов семейства Rational, разработчику нет необходимости вдаваться в детали xml-описаний.

Тем не менее, организация взаимодействия компонентов требует внесения некоторых изменений в код компонентов. В основе своей такой дополнительный код должен обеспечивать отправку данных и создание «коммуникационного канала» для того, чтобы Брокер Свойств (Property Broker) мог сообщить компоненту о поступлении новых данных.

Поведение портлетов и RCP-компонентов различается, поэтому лучше рассматривать эти два вида компонентов отдельно.

Взаимодействие портлетов

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

Взаимодействие компонентов происходит следующим образом:

Отправка сообщения из портлета

Создание привязки (wire) между портлетами полностью соответствует требованиям спецификации JSR 168. Привязка просто служит соединением между соответствующими друг другу выходными и входными свойствами. При этом тип обоих свойств должен быть один и тот же (сейчас это строки). Фрагмент Java-кода может выглядеть так (здесь wire_text – переменная или константа, которая представляет передаваемые данные):

public static final String FORM_SUBMIT = "SendMessagePortletFormSubmit";
public static final String FORM_TEXT = "wire_text";
public static final String ACTION_NAME_PARAM = "ACTION_NAME";
public static final String SEND_MESSAGE_ACTION = "MessageWireAction";

В любой момент, когда компонент-отправитель публикует для Брокера текущее значение свойства wire_text, Брокер трансформирует строку к свойству с именем wire_wsdl_text и уведомляет об этом портлет-получатель, после чего этот портлет получает сообщение и обрабатывает его требуемым образом.

Ниже приведен пример кода метода processAction() (вызываемого контейнером портлетов при выполнении определенных действий) для портлета-отправителя.

public void processAction (ActionRequest request, ActionResponse response) 
  throws PortletException, java.io.IOException 
{
  //* отправка сообщения Брокеру свойств
  String wiredText = null;
  String actionName = request.getParameter(ACTION_NAME_PARAM);
  If (SEND_MESSAGE_ACTION.equals (actionName)) 
  {
    wiredText = request.getParameter(FORM_TEXT);
    request.setAttribute(FORM_TEXT, wiredText);
  }
}

Задание значений выходных свойств происходит только при обработке событий, поэтому метод doView() портлета не связан с Брокером свойств. В приведенном ниже примере в этом методе просто происходит оповещение контейнера портлетов о том, что следует перенаправить запрос JSP-документу:

public void doView(RenderRequest request, RenderResponse response)
  throws PortletException, IOException 
{
  response.setContentType(request.getResponseContentType());
  // Передача управления JSP
  PortletRequestDispatcher rd =
    getPortletContext().getRequestDispatcher(JSP_PATH);
  rd.include(request,response);
}

Собственно посылка сообщения выполняется при помощи формы HTML в JSP-документе и протокола HTTP:

<%
PortletURL actionUrl = renderResponse.createActionURL();
actionUrl.setParameter(SendMessagePortlet.ACTION_NAME_PARAM,
  SendMessagePortlet.SEND_MESSAGE_ACTION);
%>
<form method="POST" action="<%= actionUrl.toString() %>">
  <input name="<%=SendMessagePortlet.FORM_TEXT%>" type="text">
  <input name="<%=SendMessagePortlet.FORM_SUBMIT%>" type="submit"
    value="Submit">
</form>

Получение сообщения портлетом

Обработка поступающего от Брокера свойств сообщения в портлете-получателе выполняется в коде метода processAction(), например, так:

public void processAction (ActionRequest request, ActionResponse response) 
  throws PortletException, java.io.IOException 
{
  String actionName = request.getParameter(ACTION_NAME_PARAM);
  If(RECEIVE_MESSAGE_ACTION.equals(actionName)) 
  {
    messageWired = request.getParameter(FORM_TEXT);
  }
}

Связь этого кода с WSDL-файлом осуществляется через значение константы RECEIVE_MESSAGE_ACTION, которое задает имя действия, объявленное в WSDL-файле.

WSDL-файл для привязок содержат не только информацию о регистрации выходных свойств. Помимо этого, для портлета-получателя необходимо сопоставить поддерживаемые действия (actions) с входными свойствами. Типы свойств задаются как XML-типы. С каждым действием сопоставлен один входной параметр и выходные параметры – все они тоже описаны как типы данных XML.

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

Расположение WSDL-файла задается как значение параметра дескриптора портлета (файл portlet.xml):

...
<portlet-preferences>
  <preference>
    <name>com.ibm.portal.propertybroker.wsdllocation</name>
    <value>/wsdl/SendMessage.wsdl</value>
  </preference>
</portlet-preferences>

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

Ниже приведен фрагмент определения связи в файле plugin.xml:

<extension id="com.ibm.rcp.portlet.wire" name="Portlet Wire"
  point="com.ibm.rcp.propertybroker.PropertyBrokerWire">
  <wire ordinal=""
    sourceentityid="/.DemoWire/SendMessage/default"
    sourcename="wire_text"
    sourceparam=""
    targetentityid="/.DemoWire/ReceiveMessage/default"
    targetname="MessageWireAction"
    targetparam="wire_text"
    title=""
    type="PROPERTY_TO_ACTION"/>
</extension>

Взаимодействие RCP-компонентов

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

Получение данных в RCP-компонентах

Для вызова RCP-компонентов Брокер свойств использует существующие Java-интерфейсы. Для компонентов, которые не имеют интерфейсных элементов Standard Widget.

Toolkit (SWT)/JFace, самый простой способ реализации листенера событий Брокера свойств в составе компонента – создание класса, который реализует интерфейс org.eclipse.core.command.IHandler interface. В этом случае Брокер свойств будет вызывать метод execute (ExecutionEvent event).

Признаком того, что вызов метода связан с изменением свойств компонента, является принадлежность события классу PropertyChangeEvent. Для получения типа события удобно использовать метод ExecutionEvent.getTrigger(). Ниже приведен пример кода метода execute() интерфейса Ihandler:

public Object execute(ExecutionEvent event) throws ExecutionException 
{
  if (event.getTrigger() instanceof PropertyChangeEvent) 
  {
    final Display display = Display.getDefault();
    final PropertyChangeEvent pce =
      (PropertyChangeEvent) event.getTrigger();
      ...
  }
}

Компоненты с более развитой функциональностью могут использовать обработчик, который либо реализует интерфейс org.eclipse.jface.action.Iaction, либо является классом, производным от org.eclipse.jface.action.Action. Событие, передаваемое такому обработчику в качестве аргумента, имеет тип org.eclipse.swt.widgets.Event и реализует интерфейс com.ibm.rcp.propertybroker.event.PropertyChangeEvent. В отличие от случая с реализацией Ihandler, события SWT можно просто преобразовать (с помощью механизма преобразования типов Java) к интерфейсу PropertyChangeEvent interface. Приведенный ниже фрагмент кода является примером реализации SWT-интерфейса IAction для получения данных о событиях Брокера свойств:

public void runWithEvent(Event event) 
{
  // Событие порождено Брокером свойств?
  if (event instanceof PropertyChangeEvent) 
  {
    final Display display = Display.getDefault();
    final PropertyChangeEvent finalEvent =
      (PropertyChangeEvent)event;
      ...
  }
}

Регистрация обработчика событий в Брокере свойств

Реализация обработчика событий Брокера и метода, который вызывается Брокером свойств – только часть того, что необходимо сделать. Затем нужно зарегистрировать обработчик событий в Брокере. Для этой цели используется специальная точка расширения Eclipse, которая введена на платформе Lotus Expeditor. Эта точка называется com.ibm.rcp.propertybroker.PropertyBrokerDefinitions, и в ней можно объявить обработчик с именем класса, расположение соответствующего WSDL-файла и тип действия.

Возможны три типа действия – SWT_ACTION, COMMAND или PORTLET. Для RCP-компонентов необходимо использовать тип SWT_ACTION.

...
<extension point="com.ibm.rcp.propertybroker.PropertyBrokerDefinitions">
  <handler class=
    "com.ibm.itso.compapp.carrental.creditcard.CreditCardActionHandler"
  file="... .wsdl"
  type="SWT_ACTION"/>
</extension>
...

Если вы создали WSDL-файл, реализовали класс обработчика событий и задали свойства обработчика в дескрипторе plugin.xml, то ваш RCP-компонент может получать оповещения о событиях от Брокера свойств.

Посылка данных из RCP-компонента

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

Как правило, взаимодействие компонентов посредством Брокера свойств инициируется изменением значения свойства.

Чтобы оповестить Брокер о новом значении свойства, необходимо подготовить параметры для передачи Брокеру, чтобы он смог их обработать и сообщить всем зарегистрированным компонентам-получателям о произошедшем изменении.

Прежде всего, нужно описать само свойство. Полное описание свойства должно содержать следующую информацию:

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

Приведенный ниже фрагмент кода показывает, как можно создать свойство и присвоить ему значение:

...
PropertyController prop = PropertyFactory.createProperty();
prop.setNamespace (MyConstants.PROPERTY_NAMESPACE);
prop.setName (MyConstants.PROPERTY_CAR_SIZE_INPUT);
prop.setType (MyConstants.PROPERTY_TYPE);
PropertyValue value = PropertyFactory.createPropertyValue (prop, obj.getMyParam());
...

Объявление связей (wires)

Связи определяют, какой компонент взаимодействует с каким и каким образом. В принципе, существуют способы организации взаимодействия компонентов и без использования связей, например, в «широковещательном» режиме, но это не всегда удобно или даже приемлемо.

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

Первые три параметра берутся из соответствующего WSDL-файла. Entity ID – это сочетание первичного и вторичного идентификаторов представления Eclipse. Имея эти данные, можно задавать связи между компонентами. Сделать это можно различными способами – например, добавлением «вручную» соответствующих деклараций в файл plugin.xml или с использованием программных средств, входящих, например, в состав WebSphere Portal.

Заключение

Теперь можно приступать к созданию приложений Lotus Expeditor или интеграции существующих приложений на этой платформе. На практике основное внимание нужно уделять не особенностям Expeditor, а архитектуре системы, возможностям и организации компонентов, из которых строится система, и получению навыков работы с программными инструментами, входящими в состав Lotus Expeditor, WebSphere Portal, Rational Application Developer и др. Lotus Expeditor является инструментом дизайнера и архитектора системы не в меньшей степени, чем инструментом разработчика. Если речь идет о создании реального составного приложения на платформе Expeditor с использованием портлетов и компонентов Eclipse, нужно, прежде всего, обладать практическими навыками использования таких сущностей без применения интеграционных платформ, подобных Expeditor.

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

Технология Клиент-Сервер 2007'4