Введение

Программный продукт IBM Content Analytics (ICA) может использоваться для сбора (или получения) содержимого из неструктурированных источников данных, таких как Web-страницы или текстовые файлы, а также из таблиц структурированных реляционных баз данных. После того, как ICA получает данные, он упорядочивает (или индексирует) их внутри документов, позволяющих искать и анализировать информацию.

В этой статье рассматриваются случаи, когда работа с документами в IBM® Content Analytics выходит за рамки стандартной функциональности или когда документы передаются на вход внешней системе. Пример сценария основан на запланированном поиске по Web-сайту с периодически обновляемыми страницами, содержащими объявления. Структурированное (например, дата объявления) и неструктурированное (например, текст объявления) содержимое Web-страниц собирается вместе и индексируется ICA; для каждой страницы создается отдельный документ. Созданный документ можно анализировать и использовать для запуска процесса WebSphere® Process Server (WPS), обрабатывающего входящее объявление в соответствии с бизнес-правилами. Мы расскажем вам, как реализовать этот сценарий с помощью пользовательского модуля экспорта ICA, который представляет собой обработчик событий, вызываемый ICA после создания и индексирования документа. В статье описывается начальная настройка ICA, которую необходимо выполнить перед началом использования этого модуля.

Мы интегрируем модуль экспорта ICA с внешним приложением WebSphere Application Server/JEE, отправляя документы ICA приложению через очередь Java™ Messaging Service (JMS) по протоколу SSL. Также мы объясним, как настроить очередь JMS в WebSphere Application Server, и рассмотрим ключевые моменты настройки приложений, получающих и отправляющих JMS-сообщения. Примеры для этой статьи вы можете найти в разделе Загрузка.

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

Вторая часть статьи посвящена вопросам настройки ПО промежуточного уровня. Мы расскажем о ключевых этапах настройки модуля экспорта и о его развертывании в среде ICA. Также в этом разделе мы расскажем о том, как создать и настроить очередь JMS в WebSphere Application Server.

Далее мы объясним, как запустить модуль экспорта, а также рассмотрим событие доставки документа в WebSphere Application Server и вызов последующего действия, например, запуск процесса WPS.

В начало

Разработка модуля экспорта ICA

Общая информация, требования и используемые технологии

Чтобы информацию ICA можно было использовать в других приложениях, в ICA имеется ряд функций для экспорта документов из текстовых наборов аналитических данных (описанных в статье Smarter collaboration for the education industry using Lotus Connections, Part 4: Use IBM Content Analytics to crawl, analyze, and display unstructured data, EN). Экспорт данных можно настроить несколькими способами: можно указывать различные опции вывода, выгружать документы в файловую систему в виде XML-файлов, выгружать данные в реляционную базу данных в виде набора записей, а также использовать полностью настраиваемые местоположения и форматы выгрузки, определенные в пользовательских модулях экспорта.

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

В примере, который мы будем рассматривать, внешнее приложение, принимающее экспортируемые документы (а именно страницы объявлений с Web-сайта), должно соответствовать следующим требованиям.

1. Приложению должны быть доступны все данные документа, включая содержимое, метаданные и фасеты.
2. Экспорт документов не должен зависеть от принимающего их приложения или ICA. Это означает, что никакие изменения содержимого документа в ICA или клиентском приложении не должны влиять на работу модуля экспорта. Приложение не должно зависеть от библиотек ICA.
3. Модуль экспорта должен отправлять документы в приложение с помощью асинхронных сообщений (т. е. поток модуля экспорта не должен дожидаться, пока приложение обработает содержимое документа) таким образом, чтобы ICA функционировал независимо от приложения.
4. После отправки сообщения необходимо получить гарантированное подтверждение того, что оно было доставлено внешнему приложению.
5. Для предотвращения подделки и перехвата данных канал связи между модулем ICA и приложением, принимающим сообщения, должен быть защищен с помощью протокола SSL.

Процесс WPS упакован в приложение Service Component Architecture (SCA) и выполняется на сервере WebSphere Process Server B7.0. Реализация процесса, а также создание и развертывание пакетов SCA-приложений выходят за рамки этой статьи. В статье "Business Process Management Samples: EJB API — Overview" (раздел Ресурсы) описываются API-функции Business Process Choreographer (BPC), рассказывается, как написать клиентское приложение, использующее API-интерфейс BPC, а также детально рассматривается процесс создания входных и выходных данных.

В соответствии с требованием п. 5 очередь JMS будет настроена таким образом, чтобы предотвратить неавторизованные подключения и разрешить использование SSL для защиты канала данных.

Обзор архитектуры интеграции

Архитектура интеграции всех компонентов изображена на рисунке 1. В верхней части изображен сервер, на котором запущен экземпляр ICA. Когда новый документ появляется в индексе, он экспортируется с помощью пользовательского модуля, который является отдельным Java-приложением, запускаемым ICA в отдельном процессе. Модулю доступны содержимое документа и метаданные, полученные из его аннотаций. Модуль подключается по защищенному каналу к очереди JMS на сервере WPS с помощью объекта javax.jms.Queue и посылает сообщение, содержащее информацию документа обоих типов (более подробно об этом рассказывается в разделе Реализация модуля экспорта).

На сервере WPS размещается и запускается приложение JEE, содержащее компонент MDB, подключенный к очереди. Когда в очередь на сервере WPS доставляется сообщение, выполняется метод обратного вызова MDB, в процессе которого информация извлекается из сообщения и используется для запуска процесса WPS, являющегося частью другого SCA-приложения, запущенного на сервере WPS. Взаимодействие между компонентом MDB и процессом обеспечивается API-функциями Business Process Choreographer, основанными на EJB; благодаря этому SCA-приложение и MDB можно запускать на разных физических серверах, что упрощает масштабирование. Использование удаленных интерфейсов EJB позволяет выполнять приложения MDB и приложения SCA на различных физических серверах. Однако использование удаленных интерфейсов приводит к загрузке сети, даже если эти приложения используют один и тот же экземпляр сервера приложений (в этом случае использование локальных интерфейсов может помочь повысить быстродействие). В этой статье предполагается, что приложения SCA и MDB располагаются внутри одного и того же экземпляра WebSphere Application Server.

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

Инфраструктура, обеспечивающая связь между модулем экспорта и компонентом MDB, а также обработку сообщений, реализована посредством шины WebSphere Service Integration (SI). Шина – это некое логическое представление, которое можно представлять себе как набор участников (серверов приложений или кластеров), использующих общую инфраструктуру для обмена сообщениями. Каждый участник шины содержит ряд механизмов обмена сообщениями, которые управляют такими ресурсами времени выполнения, как очереди, и отвечают за хранение сообщений в файлах, оперативной памяти или базах данных. Механизмы обмена сообщениями позволяют клиентским приложениям подключаться к очередям JMS и другим пунктам назначения шины SI. MDB отвечает за прием сообщений, отправленных модулем экспорта, и использует для подключения к очереди JMS спецификацию активации (определенный набор параметров подключения).

Компоненты шины SI и их связи с приложением MDB изображены на рисунке 2.

Конфигурация WebSphere Application Server обеспечивает использование защищенного транспортного канала для взаимодействия между клиентами и шиной, а также разрешает доступ к пунктам назначения очереди только авторизованным пользователям.

Реализация модуля экспорта

Модуль экспорта ICA должен быть унаследован от класса com.ibm.es.oze.api.export.ExportDocumentPublisher, и в нем должен быть реализован абстрактный метод этого класса publish(), который принимает на вход единственный параметр – экземпляр класса com.ibm.es.oze.api.export.document.Document, представляющий собранный и проанализированный документ.

Чтобы избежать лишних связей между внешним приложением и ICA, перед отправкой документов в виде JMS-сообщений они конвертируются в универсальный плоский формат. Все поля документа (язык, тип документа, источник и т. д.) и данные фасета помещаются в таблицу. Ключами таблицы являются строки с префиксом "field." или "facet.", совпадающие с именами полей или путями фасетов (в случае иерархических фасетов, являющихся вложенными уровнями классификации) и представляющие собой объединенные элементы пути, разделенные, например, конструкцией ‘ > ‘ — "word > num". Значениями таблицы являются значения полей документов или ключевые слова фасетов. Результирующая таблица помещается в сообщение типа javax.jms.MapMessage и передается через JMS.

Хотя класс Document можно преобразовать в объект javax.jms.ObjectMessage и передать через JMS в двоичном формате, использование не зависящего от формата текстового сообщения позволяет приложению, принимающему данные, не зависеть от способа реализации класса Document в библиотеках ICA.

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

Реализация метода publish() модуля экспорта состоит из нескольких шагов. Сначала выполняется проверка типа документа: метод publish() вызывается даже при удалении документа из индекса, однако в нашем примере это не влияет на обработку этой ситуации. Далее выполняется вызов вспомогательной процедуры для получения "плоского" представления документа, которое затем передается в метод sendMessage() экземпляра com.ibm.tonkawa.cca.jms.MessageSender, инициализированный в конструкторе модуля.

Класс com.ibm.tonkawa.cca.jms.MessageSender отвечает за обработку заданий, связанных с JMS. Он устанавливает подключение к очереди сообщений и отправляет сообщения. Конструктор этого класса принимает на вход два аргумента: параметры инициализации и предварительно настроенный экземпляр регистратора. Объект свойств содержит следующие данные:

• URL-адрес провайдера JNDI в виде corbaname:iiop:<имя_хоста>:<порт>.
• Полное имя класса, реализующего интерфейс javax.naming.InitialContextFactory.
• JNDI-имя очереди.
• JNDI-имя фабрики соединений.
• Имя пользователя, которому разрешено выполнять поиск JNDI. Для простоты очередь настроена таким образом, что помещать в нее сообщения может единственный пользователь.
• Пароль пользователя.
• URL-адрес конфигурационного файла подключения Java Authentication and Authorization Service (JAAS). Подробную информацию вы можете найти в статье "JAAS Login Configuration File" (раздел Ресурсы).
• URL-адрес конфигурационного файла, содержащего параметры аутентификации Internet Inter-Orb Protocol (IIOP) для тонких клиентов приложений, работающих под управлением WebSphere Application Server.
• URL-адрес конфигурационного файла SSL.

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

System.setProperty("java.security.auth.login.config", jaasLoginConfig);
System.setProperty("com.ibm.CORBA.ConfigURL", corbaConfigUrl);
System.setProperty("com.ibm.SSL.ConfigURL", sslConfigUrl);

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

Подключение к очереди осуществляется в методе initMessagingFacility() в соответствии со следующей последовательностью действий:

1. С помощью специальной первичной фабрики контекста создается экземпляр javax.naming.InitialContext.
2. Создается экземпляр javax.security.auth.login.LoginContext, после чего выполняется аутентификация.
3. После прохождения аутентификации модуль подключения создает экземпляр javax.security.auth.Subject. Субъект, содержащий учетные данные CORBA, используется службой авторизации для дальнейшей установки ограничений на доступ к ресурсам JNDI.
4. Субъект используется для выполнения обратного вызова от имени пользователя, указанного в параметре инициализации MessageSender. При этом в контексте JNDI осуществляется поиск объекта javax.jms.ConnectionFactory, который используется для получения экземпляра javax.jms.Connection. Также осуществляется поиск объекта javax.jms.Queue, который вместе с объектом Connection помещается в простой объект Data-Transfer Object (DTO), передающийся обратно.

Этот процесс представлен в листинге 2.

private void initMessagingFacility()
    throws NamingException, LoginException
{
    Properties env = new Properties();
    env.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
    env.put(Context.PROVIDER_URL, providerUrl);
    
    final InitialContext initialContext = new InitialContext(env);
    
    /*
     * Фиктивный вызов для установки доменов безопасности JAAS.
     * Этот вызов должен быть сделан до начала входа в JAAS.
     */
    initialContext.lookup(providerUrl);
    
    CallbackHandler loginCallbackHandler = new WSCallbackHandlerImpl(
        jaasUser, jaasPassword
    );
        
    LoginContext lc = new LoginContext("WSLogin", loginCallbackHandler);
    lc.login();
    Subject subject = lc.getSubject();
    
    PrivilegedAction<MessagingWrapper> postMessage = \
new PrivilegedAction<MessagingWrapper>()
    {
        public MessagingWrapper run()
        {
            try
            {
                Object lookedUp = initialContext.lookup(jmsConnectionFactoryName);
                ConnectionFactory connectionFactory = \
(ConnectionFactory) PortableRemoteObject
                        .narrow(lookedUp, ConnectionFactory.class);
                
                lookedUp = initialContext.lookup(jmsQueueName);
                Queue queue = (Queue) PortableRemoteObject.narrow(lookedUp, Queue.class);
                
                Connection connection =
                    connectionFactory.createConnection(jaasUser, jaasPassword);

                return new MessagingWrapper(connection, queue);
            }
            catch (NamingException e)
            {
                logger.log(Level.SEVERE, "Failed to lookup \
connection factory and queue", e);
                throw new MessagingException("Failed to lookup \
connection factory and queue",e);
            }
            catch (JMSException e)
            {
                logger.log(Level.SEVERE, "Failed to \
create JMS connection", e);
                throw new MessagingException("Failed to \
create JMS connection", e);
            }
        }
    };
    
    MessagingWrapper wrapper = (MessagingWrapper) WSSubject.doAs(subject, postMessage);
    connection = wrapper.getConnection();
    queue = wrapper.getQueue();
    
    if (logger.isLoggable(Level.INFO))
    {
        logger.log(Level.INFO, "Connection: " + connection);
        logger.log(Level.INFO, "Queue: " + queue);
    }
}

Метод initMessagingFacility() вызывается только один раз перед отправкой JMS-сообщения в соответствии со следующей последовательностью действий:

1. С помощью подключения к очереди создается экземпляр (сеанс) javax.jms.Session.
2. С помощью сеанса мы получаем доступ к объекту класса javax.jms.MessageProducer. Для доставки сообщений в пункт назначения используется поставщик сообщений. Существуют опции, позволяющие задавать режим доставки, приоритет и время жизни сообщений. Режим доставки (NON_PERSISTENT или PERSISTENT) определяет для JMS-провайдера необходимость обеспечения гарантированной доставки сообщений. Параметр Priority (приоритет) определяет очередность доставки сообщений JMS-провайдером. Параметр Time-To-Live (время жизни) определяет время жизни сообщений; сообщения, которые не были доставлены получателю в заданный срок, сбрасываются.
3. С помощью объекта сеанса создается экземпляр табличного сообщения. Табличное сообщение – это набор записей вида "ключ-значение", которые хорошо подходят для использования в плоских документах, как это описывалось в предыдущем разделе.
4. Табличное сообщение заполняется данными и передается через поставщика сообщений.

В базовом классе модуля экспорта определен обратный вызов term() для завершения сеанса экспорта данных. В нем реализован вызов метода cleanup() объекта MessageSender, закрывающего и освобождающего все используемые ресурсы JMS.

В начало

Реализация клиентского приложения

Клиентское приложение является объектом MDB, упакованным в архив Enterprise Archive (EAR) и развернутым на сервере WebSphere Application Server. Объект MDB реализует единственный метод onMessage(), унаследованный из интерфейса javax.jms.MessageListener.

В интерфейсе onMessage() входящее сообщение приводится к классу типа MapMessage, после чего выполняется итерация по всем его свойствам для построения хэш-таблицы, содержащей все данные документа, передаваемые в сообщении. Затем таблица передается в качестве аргумента методу start() объекта MDB, реализующему использование API-функции BPC. Для краткости мы не будем приводить подробный листинг метода start(); вы можете найти его в приложении этой статьи (раздел Загрузка).

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

В листинге 3 показан скелет реализации объекта MDB.

@MessageDriven(
    activationConfig = {
        @ActivationConfigProperty(
            propertyName = "destinationType", propertyValue = "javax.jms.Queue"
        )
    }
)
@RunAs(TonkawaRoles.TONKAWA)
public class RecommendationMessageHandler implements MessageListener
{
    /** Экземпляр регистратора. */
    private static final Logger LOGGER = Logger
            .getLogger(RecommendationMessageHandler.class.getName());
    
    @PersistenceContext(unitName = "tonkawa-core")
    private EntityManager manager;
    @Resource
    private MessageDrivenContext context;
    
    public void onMessage(Message message)
    {
        if (LOGGER.isLoggable(Level.FINE))
        {
            LOGGER.log(Level.FINE, "Message received: " + message);
        }
        
        try
        {
            MapMessage mapMessage = (MapMessage) message;
            
            Enumeration<String> names = mapMessage.getMapNames();
            Map<String, String> documentData = new HashMap<String, String>();
            while (names.hasMoreElements())
            {
                String key = names.nextElement();
                documentData.put(key, mapMessage.getString(key));
            }

            SampleProcessWrapper wrapper = new SampleProcessWrapper();
            wrapper.start(documentData);
        }
        catch (Exception e)
        {
            context.setRollbackOnly();
            LOGGER.log(Level.SEVERE, "Exception occurred", e);
        }
    }
}

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

Также обратите внимание на то, как запускается процесс WPS в последних нескольких строках блока try. Интерфейсный класс представляет собой клиент, работающий с функциями EJB API процесса и реализующий задачи поиска JNDI менеджера Business Flow Manager. Он выполняет поиск шаблона процесса, упаковывает входные данные в объект SDO и запускает процесс посредством вызова метода start(), как описывалось ранее.

В начало

Конфигурация ПО промежуточного уровня

Конфигурация модуля экспорта ICA

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

Мы использовали следующие переменные среды:

ICA_ROOT – установочная директория ICA (например, C:\ICA22\es).

WAS_ROOT – установочная директория WebSphere Application Server (например, D:\Additional Programs\WID_WTE\runtimes\bi_v7).

Для инициализации экземпляра MessageSender (см. раздел Реализация модуля экспорта) необходимо задать значения нескольких параметров. В нашем примере (см. раздел Загрузка) они считываются из файла, показанного в листинге 4.

# URL поставщика JNDI. Необходимо указывать в виде corbaname:iiop:<хост>:<порт>
# Убедитесь, что этот узел доступен; при необходимости добавьте запись в /etc/hosts.
 jms.jndi.provider.url=corbaname:iiop:bps:2810
# Имя класса InitialContextFactory. Не меняйте эту строку.
 jms.jndi.initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory
# JNDI-имя очереди, в которую будут помещаться сообщения
 jms.jndi.queueName=jms/TonkawaQueue
# JNDI-имя фабрики соединений, использующееся для подключения к очереди
 jms.jndi.connectionFactoryName=jms/TonkawaConnectionFactory

# Имя пользователя, которому разрешено выполнять поиск JNDI.
# В данный момент предполагается, что этому же пользователю разрешено
# помещать сообщения в очередь.
 jms.jaas.user=wasadmin
jms.jaas.password={xor}Lz4sLChvLTs=

 java.security.auth.login.config=file:\
///C:/Program Files/IBM/es/esadmin/plugin_config/signaller/wsjaas_client.conf
 com.ibm.CORBA.ConfigURL=file:\
///C:/Program Files/IBM/es/esadmin/plugin_config/signaller/sas.client.props
 com.ibm.SSL.ConfigURL=file:\
///C:/Program Files/IBM/es/esadmin/plugin_config/signaller/ssl.client.props

Последние три строки объясняются в следующем разделе.

Чтобы модуль экспорта мог связываться с JMS-сервером по защищенному каналу, он должен иметь доступ к следующим файлам:

• wsjaas_client.conf
• sas.client.props
• ssl.client.props

В этих файлах содержится конфигурация, используемая при взаимодействии с сервером через RMI-IIOP. Эти файлы должны быть загружены на сервер ICA из директории %WAS_ROOT%\profiles\<профиль>\properties сервера WebSphere Application Server или сервера WPS, на котором создана очередь.

Файлы должны быть помещены в доступное местоположение, а параметры конфигурации модуля экспорта должны ссылаться на него (см. пример в предыдущем разделе).

Важно. Убедитесь, что пути указаны в формате URL (т. е. начинаются с file:///).

Затем с сервера, на котором запущен компонент JMS, на сервер ICA должны быть загружены доверенное хранилище и хранилище ключей. Местоположения этих файлов можно посмотреть в файле properties/ssl.client.props, расположенном в директории профиля сервера, как показано в листинге 5.

 ...
 user.root=C:/WDPE_WTE/runtimes/bi_v7/profiles/ProcSrv01
 ...
 com.ibm.ssl.trustStore=${user.root}/etc/trust.p12
 com.ibm.ssl.keyStore=${user.root}/etc/key.p12

После загрузки ключей файл ssl.client.props, расположенный на сервере ICA, необходимо изменить в соответствии с их новым местоположением, т. е. необходимо исправить значения следующих параметров:

• user.root
• com.ibm.ssl.trustStore
• com.ibm.ssl.keyStore

Поскольку модуль экспорта зависит от классов JMS и выполняет поиск JNDI-объектов из контекста именования WebSphere, зависимости классов должны быть загружены посредством JVM. В силу некоторых особенностей загрузки классов это требование оказывается еще более строгим. Необходимо, чтобы эти классы присутствовали в пути к классу Java-процесса, поэтому пользовательской реализации класса URLClassLoader недостаточно. Таким образом, для настройки пути к классу процесса модуля необходимо выполнить следующие действия:

1. Загрузите из директории %WAS_ROOT%\runtimes сервера, с которым необходимо обеспечить взаимодействие, следующие файлы:

• com.ibm.ws.ejb.thinclient_7.0.0.jar;
• com.ibm.ws.sib.client.thin.jms_7.0.0.jar.

1. Поместите эти файлы в директорию %ICA_ROOT%\lib.
2. В файле %ICA_ROOT%\configurations\interfaces\indexservice__interface.ini найдите строку, начинающуюся с "classpath", и добавьте в ее конец следующий текст: ,com.ibm.ws.ejb.thinclient_7.0.0.jar,com.ibm.ws.sib.client.thin.jms_7.0.0.jar.

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

1. В Web-приложении System Administration перейдите в 'Collections' и нажмите 'Edit' для той коллекции, для которой необходимо будет запускать модуль экспорта.
2. По окончании загрузки страницы переместитесь на вкладку 'Export' и выберите 'Configure options to export crawled or analyzed documents'.
3. В разделе 'Options for exporting analyzed documents' установите переключатель 'Export documents by using a custom plug-in'.
4. В поле 'Export plug-in class path' укажите JAR-файл, содержащий модуль экспорта.
5. Укажите имя класса модуля в поле 'Class name' сервера публикаций (например, com.ibm.tonkawa.cca.plugin.SignallerPlugin).
6. Сохраните изменения.
7. В Web-приложении System Administration перейдите в 'Collections' и нажмите 'Parse and Index' для нужной коллекции. На вкладке 'Parse and Index' следующей страницы запустите процесс индексатора.

Конфигурация WebSphere Application Server

В этом разделе мы расскажем о том, как создать и настроить для ICA шину SI на сервере WebSphere Application Server.

1. Создайте псевдоним JAAS, в котором будут храниться идентификатор и пароль пользователя, необходимые для аутентификации при создании нового подключения к поставщику JMS. Чтобы упростить конфигурацию, мы будем использовать для этого псевдонима учетные данные wasadmin.
2. Создайте шину SI. Для авторизации взаимодействий между механизмами обмена сообщениями шины используется псевдоним JAAS, созданный на предыдущем шаге.
3. Добавьте сервер WebSphere Application Server в состав участников шины SI.
4. Создайте пункт назначения очереди шины SI. Дополнительно вы можете задать уровень надежности доставки сообщений. В нашем случае было выбрано значение ASSURED_PERSISTENT, гарантирующее, что сообщения не будут сбрасываться.
5. Создайте фабрику соединений, подключенную к шине SI.
6. Создайте очередь.
7. Создайте спецификацию активации MDB-приложения. JNDI-именем пункта назначения должно являться JNDI-имя очереди, созданной на шаге 6, а именем псевдонима JAAS должно являться имя, определенное на шаге 1.

Хотя все эти действия можно выполнить из консоли WebSphere Application Server Admin, для более эффективного развертывания можно использовать сценарий Jython для инструмента wasadmin (см. раздел Загрузка), позволяющий выполнять административные задачи и автоматизировать процесс конфигурирования WebSphere Application Server. Помимо вышеперечисленных действий, в этот сценарий также включены команды для инсталляции и запуска MDB-приложения.

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

# Учетные данные администратора WebSphere.
userName = "wasadmin"
password = "123456"

# Сервер, добавляемый в качестве участника шины.
server = "server1"
fqdn = "myhost.com"

# Параметры установки EAR
appPath = "C:/sample.ear"
deployToServers = [ "webserver1", "server1" ]

Для запуска сценария откройте инструмент wasadmin, как описано в разделе Starting the wsadmin scripting client using wsadmin scripting (EN) справочной системы WebSphere Application Server V7 InfoCenter.

В результате вы попадете в оболочку wasadmin, в которой можно выполнять команды Jython или Jacl. Для запуска сценария наберите команду execfile(), как показано ниже:

 wsadmin> execfile("<путь>\install.py")

По мере выполнения сценарий формирует подробный вывод с сообщениями о ходе процесса.

В начало

Запуск модуля и наблюдение за результатами

На этом этапе все готово к тому, чтобы запускать все компоненты приложения и наблюдать за результатами работы.

Предположим, что приложения SCA и MDB уже развернуты и запущены, и убедимся в том, что сборщик ICA и индексатор для определенной коллекции документов также выполняются. Это можно сделать с помощью Web-приложения ICA System Administration, перейдя в 'Collections' и выбрав требуемую коллекцию. Вкладки 'Crawl' и 'Parse and Index' содержат элементы управления соответствующей службой. Это показано в верхней части рисунка 3.

Модуль экспорта запускается одновременно с индексатором. В этом можно убедиться, просмотрев log-файл модуля (для этого должен быть настроен регистратор, см. раздел Реализация модуля экспорта), как показано в листинге 7.

Initializing message sender...
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: Provider URL: corbaname:iiop:bps.renovations.com:2810
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: Initial context factory: com.ibm.websphere.naming.WsnInitialContextFactory
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: Queue name: jms/TonkawaQueue
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: Connection factory name: jms/TonkawaConnectionFactory
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: JAAS user: wasadmin
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: JAAS login config: file:///C:/CCA_plugin/signaller/wsjaas_client.conf
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: CORBA config: file:///C:/CCA_plugin/signaller/sas.client.props
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.jms.MessageSender assertProperties
INFO: SSL config: file:///C:/CCA_plugin/signaller/ssl.client.props
Mar 3, 2011 5:56:24 AM com.ibm.tonkawa.cca.plugin.PluginLogger flush
INFO:
Message sender initialized...

Следующим шагом необходимо создать тестовый документ, доступный сборщику. Если сборщик ищет информацию на Web-страницах, для этого достаточно опубликовать Web-страницу на локальном сайте под управлением IBM HTTP Server. Если сборщик ищет данные в файловой системе, нужно поместить документ в директорию, за которой наблюдает сборщик. После этого перейдите на страницу подробных сведений о сборщике и нажмите 'Start full recrawl', как показано в нижней части рисунка 3.

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

Mar 3, 2011 8:20:21 AM com.ibm.tonkawa.cca.plugin.SignallerPlugin sendMessage
FINE: Flattened doc: {<content skipped>}
Mar 3, 2011 8:20:23 AM com.ibm.tonkawa.cca.jms.MessageSender sendMessage
INFO: Sending message...

На доставку сообщения, его обработку и запуск нового бизнес-процесса может уйти несколько секунд. Событие запуска можно отследить в приложении Business Process Choreographer Explorer, установленном на портале WPS. Войдите в это приложение и перейдите в ветку 'Started by me' узла 'Process Instances', чтобы просмотреть недавно созданные экземпляры бизнес-процесса.

В начало

Заключение

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

В начало

Загрузка

Информация о методах загрузки

Ресурсы

Научиться

• Оригинал статьи: Implement a custom export plug-in for IBM Content Analytics to emit WebSphere Service Integration Bus events (EN).
  
  
• Чтобы ознакомиться с основными понятиями ICA, такими как документы, коллекции и конвейеры обработки, обратитесь к статье IBM Content Analytics (EN).
  
  
• Чтобы научиться создавать и настраивать коллекции документов и сборщики, прочитайте статью Smarter collaboration for the education industry using Lotus Connections, Part 4: Use IBM Content Analytics to crawl, analyze, and display unstructured data (EN).
  
  
• В справочном разделе WebSphere Application Server Version 7.0 Information Center (EN) вы найдете полную информацию о настройке шины Service Integration Bus в WebSphere Application Server.
  
  
• Внимательно изучите справочную систему IBM WebSphere Process Server Information Center, чтобы понять, как осуществляется развертывание приложений SCA.
  
  
• Узнайте, как использовать функции WPS EJB API, прочитав статью Business Process Management Samples: EJB API — Overview (EN).
  
  
• В документе JSR 220: Enterprise JavaBeans 3.0 (EN) подробно рассказывается о контракте управляемых сообщениями компонентов (Message-Driven Bean, MDB).
  
  
• Документ JSR 914: Java Message Service (JMS) API (EN) определяет порядок использования служб обмена сообщениями в приложениях Java EE.
  
  
• В руководстве JAAS Login Configuration File (EN) описаны различные конфигурационные параметры настройки пользовательских модулей авторизации.
  
  
• Из статьи Securing JMS connections to WebSphere Enterprise Service Bus V6.1 or V6.2 (EN) вы узнаете об основах настройки безопасности шины Service Integration Bus.
  
  
• В руководстве IBM Redbook IBM WebSphere Application Server V6.1 Security Handbook (EN) вы найдете подробные инструкции по настройке различных аспектов безопасности приложений.
  
  
• В статье Deploying message-driven beans and JMS applications into the Service Integration Bus (EN) представлено пошаговое руководство по развертыванию компонентов MDB на шине Service Integration Bus под управлением WebSphere Application Server.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Следите за блогом developerWorks в Твиттере (EN).
  
  

Об авторах

Владислав Пономарев (Vladislav Ponomarev) – руководитель команды разработчиков Web-решений IBM Russian Software and Technology Lab. Его основными направлениями деятельности являются приложения Java EE, виртуализация и облачные вычисления.

Карл Осипов (Carl Osipov) - архитектор ПО, подразделениe стратегий и технологий IBM Software Group. Обладает большим опытом в области распределенных вычислений, разработке приложений по распознаванию живой речи и компьютерной обработке естественного языка. Имеет ряд публикаций и выступлений по вопросам Сервис-ориентированной архитектуры и управлением разпознования речи перед образовательской и бизнес аудиторией. На данный момент он в основном занимается проектированием технологий повторного использования для составных бизнес-сервисов.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Разработка модуля экспорта ICA
• Реализация клиентского приложения
• Конфигурация ПО промежуточного уровня
• Запуск модуля и наблюдение за результатами
• Заключение
• Загрузка
• Ресурсы
• Об авторах
• Комментарии