WebSphere Process Server (здесь и далее Process Server) активизирует модули и компоненты SCA (Service Component Architecture) как сервисы компонентов. Такая активизация, определенная связыванием сервисов (service binding), может быть либо синхронной, либо асинхронной. Неожиданный сбой в модуле перенаправляет сообщение. То, как направляются и обрабатываются сообщения, зависит от выбора связывания.

Связывания SCA и Web-сервисов являются синхронными. Синхронная активизация блокирует работу после запроса адресату до получения ответа (успех или неудача). То есть, системная исключительная ситуация распознается сразу после активизации, и вызов сервиса прекращается. Именно сторона, вызывающая сервис, принимает решение, повторить ли вызов.

В асинхронном связывании вызывающая сторона передает сообщение провайдеру сервиса через систему обмена сообщениями, а затем переключается на другую работу. Если сервис имеет двунаправленный интерфейс, вызывающая сторона ожидает ответное сообщение; однако при однонаправленном интерфейсе вызывающая сторона не ждет какого-либо ответа. В любом случае сторона, вызвавшая сервис, не "остается на линии" и не знает, "завис" ли провайдер сервиса. Тем не менее, инфраструктура должна быть надежной и гарантировать обработку каждого сообщения даже в случае сбоев в системе. Асинхронное связывание поддерживает три типа связывания сообщений: JMS, MQ и MQ JMS.

Исключительные ситуации делятся на две основные категории: прикладные или системные.

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

Системные исключительные ситуации возникают тогда, когда происходит сбой определенной части инфраструктуры (например, не работает база данных или Web-сервис партнера не доступен), когда возникает нарушение контракта активизации (например, инициатор вызова сервиса передает данные в формате, отличном от ожидаемого провайдером сервиса, возможно, из-за несоответствия версий), а также в случае неожиданных ошибок в исходном коде (например, необрабатываемые исключительные ситуации в Java). Задача заключается в обеспечении гарантии того, что все активизации сервиса учитываются и не теряются даже в случае возникновения системных исключительных ситуаций.

Данная статья создана на базе публикации developerWorks "Обработка исключительных ситуаций в WebSphere Process Server и WebSphere Enterprise Service Bus" Памелы Фонг (Pamela Fong) и Джеффа Брента (Jeff Brent) (ссылка приведена в разделе "Ресурсы").

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

• IBM WebSphere Process Server V6.0.2.2
• IBM WebSphere MQ V6.0.2.2

Сценарии восстановления сообщений, которые могут быть различными, зависят от типа используемой системы обмена сообщениями, конфигурации системы и места возникновения исключительной ситуации. Process Server поддерживает связывание асинхронных SCA-интерфейсов с двумя системами обмена сообщениями: встроенной WebSphere Default Messaging и WebSphere MQ, доступной либо через JMS-интерфейс (здесь и далее MQ JMS-связывание), либо через встроенный MQ-интерфейс (MQ-связывание).

Для любой системы доставка сообщений в асинхронной схеме активизации является двухэтапным процессом (см. рисунок 1). Модуль Export использует сервис MDB-прослушивателя JMS (или MQ) для прослушивания адресата. Когда сообщение достигает очереди адресата, активизируется JMS MDB модуля export; затем выполняется обработка, включая десериализацию объекта и выбор функции. Затем SCA-сообщение направляется в SCA MDB для доставки компоненту target. По соображениям производительности SCA MDB обходится во время первой попытки доставки сообщения.

Мы убедились в таком взаимодействии MDB, просмотрев трассировку стека Java, генерируемую при системных ошибках. Из этой трассировки можно увидеть, что в первый раз, когда исключительная ситуация генерируется в компоненте, сообщение извлекается MDB-классом, специфичным для связывания export, таким как com.ibm.wsspi.sca.mq.inbound.MQInboundImpl или com.ibm.wsspi.sca.jms.inbound.MQJMSInboundImpl.

Когда передача сообщения повторяется, этот MDB больше не принимает участия в работе; однако сообщение извлекается MDB-классом SCA com.ibm.wsspi.sca.async.bean.impl.ServiceSIBusMessageBean. Этап от одного MDB к другому завершается перемещением сообщения из оригинального адресата модуля export адресату Service Integration Bus (SIB), сгенерированному для модуля export сервером Process Server. MDB MQ (MQ JMS или JMS) пытается перемещать сообщения, когда распознает, что входящие сообщения были предварительно доставлены. Если механизм системы обмена сообщениями SIB недоступен, генерируется другая исключительная ситуация, а сообщение направляется назад оригинальному адресату. Пример генерирования исключительной ситуации при недоступности механизма обмена сообщениями предоставлен в файле SIB_ME_stopped.txt, который вы можете загрузить.

Рисунок 1. Начальная маршрутизация сообщения модулем SCA Export

Все SCA-компоненты в Process Server активизируются посредством Java - системные исключительные ситуации представляются как com.ibm.websphere.sca.ServiceRuntimeException, подкласс java.lang.RuntimeException. Если во время работы компонента возникает системная ошибка, исключительная ситуация передается обратно вниз по стеку Java-вызовов вызывающему компоненту и далее вниз по цепочке вызовов компонентов до тех пор, пока не достигнет SCA MDB.

Если в цепочке вызовов имеется асинхронная активизация, исключительная ситуация достигает MDB, который получил последний асинхронный вызов и который прослушивает соответствующий SIB-адресат. Если все активизации компонентов в модуле были синхронными, этот MDB будет единственным, прослушивающим модуль export. В этом случае сообщение сначала направляется обратно адресату системы обмена сообщениями, с которым связан модуль export (SIB или MQ). Аналогично, если системная ошибка происходит во время работы модуля export (десериализация объекта или выбор функции), сообщение тоже направляется назад адресату системы обмена сообщениями, из которого оно было извлечено.

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

Если системная исключительная ситуация передается назад в асинхронно активизированный компонент, сообщение направляется обратно в SIB-очередь, соответствующую этому компоненту. Оно извлекается MDB-компонентом, прослушивающим очередь. Счетчик повторов для сообщения увеличивается на единицу, и снова производится попытка доставить сообщение. Логика повторных попыток для SIB-адресатов одинакова и не зависит от того, используется адресат для асинхронного компонента или для модуля export. Это логика рассматривается ниже.

В ситуации с WebSphere Default Messaging логика повторов указывается путем установки свойств SIB-адресата: счетчик Maximum failed deliveries и Exception destination. Используйте консоль Integrated Services Console (то есть Web-интерфейс администратора WebSphere Process Server) и выберите Buses => SIB name => Destinations => SIB Destination name. Затем установите эти два свойства в окне SIB Destination properties, как показано на рисунке 2.

Рисунок 2. Настройка адресата исключительной ситуации для SIB-очереди

Счетчик повторов доставки адресата SIB-очереди управляет числом попыток, производимых для доставки сообщения целевому компоненту в случае сбоев. Если сообщение направляется обратно указанное для очереди число раз, оно направляется адресату исключительной ситуации.

Для модуля exports с JMS-связыванием и SCA-компонентами система времени исполнения Process Server автоматически генерирует адресат SIB-очереди при развертывании SCA-модуля. Для этой автоматически сгенерированной SIB-очереди адресат исключительной ситуации установлен в очередь Failed Event. Сообщения, переданные в очередь Failed Event, извлекаются MDB-компонентом менеджера Failed Event. В адресатах автоматически сгенерированной очереди максимальное количество попыток доставки установлено в значение 5. Это означает, что сообщение будет перемещаться после пяти сбоев. Дополнительная информация по этой логике повторных попыток и настройкам SIB-адресатов приведена в статье developerWorks "Обработка исключительных ситуаций в WebSphere Process Server и WebSphere Enterprise Service Bus" Памелы Фонг (Pamela Fong) и Джеффа Брента (Jeff Brent).

JMS-адресаты SIB подключаются к MDB-компонентам через спецификацию активизации, а не через порты прослушивателя. Спецификации активизации не имеют функциональности управления вредными сообщениями, которая останавливает прослушиватель. Этого не требуется, поскольку функциональность управления испорченными сообщениями обеспечивается SIB-адресатом (путем установки свойств адресата исключительной ситуации). То есть, в случае JMS-связывания конфигурируется на один объект меньше.

Испорченное сообщение (poison message) - это сообщение, которое не может быть обработано принимающим приложением и периодически возвращающееся назад целевому адресату. Управление испорченными сообщениями - это функциональность инфраструктуры, целью которой является предотвращение бесконечной доставки, сбоев в работе и возврат испорченных сообщений.

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

В ситуации с MQ (либо MQ-связывание, либо MQ JMS-связывание) логика повтора управляется свойствами локальной очереди: backout threshold (предельное число повторов - BOTHRESH) и backout requeue queue (очередь возвратов - BOQNAME). Эти свойства можно найти в MQ Explorer в закладке Storage.

MQ Support Pack MO71, либо вашу любимую инструментальную программу (например, MQ Explorer), либо написать специальный сценарий.

WebSphere MQ Support Pack MO71 (GUI Administrator) - это простая GUI-программа для администрирования менеджеров локальных и удаленных очередей. Для восстановления сбойных сообщений можно использовать следующие возможности:

• Просмотр очередей и отдельных сообщений, включая все MQ-заголовки.
• Сохранение сообщения в файл и загрузку сообщения из файла, что позволяет редактировать его в многочисленных сторонних программах по вашему выбору, наиболее подходящих для типа содержимого сообщения.
• Помещение сообщения в произвольную очередь. Функциональность перемещения сообщения соответствует функциональности "resubmit message" Failed Event Manager в мире SIB.

Рисунок 4. Просмотр сбойного сообщения в MQ Support Pack MO71

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

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

Как для MQ-связывания, так и для SIB-связывания восстановление после системных ошибок состоит из планирования (настройка ресурсов системы обмена сообщениями с возможностью восстановления), исследования сбоя и повторной передачи сообщения (помещение сообщения обратно в очередь обработки, возможно, после редактирования). Используемые инструментальные средства восстановления и процедура зависят от системы обмена сообщениями (SIB или MQ), участвующей в перемещении сообщения в очередь requeue или адресату исключительной ситуации. Как рассматривалось выше, для MQ- или MQ JMS-связывания сообщение может передаваться адресату исключительной ситуации SIB, если сбой произошел после асинхронного вызова в SCA-модуле. Поэтому всегда используйте инструментальные программы SIB для восстановления в MS-связанных сервисах, но, возможно, понадобятся инструментальные программы и MQ, и SIB для восстановления MQ-связанных и MQ JMS-связанных сервисов.

Инструментальной программой SIB является Failed Event Manager. Она предоставляет удобный Web-интерфейс и является частью консоли Integrated Solutions Console, которая является основным Web-средством администрирования для семейства WebSphere Application Server, включая WebSphere Process Server (этот интерфейс раньше назывался "Admin Console"). Полная интеграция с платформой WebSphere дает программе Failed Event Manager несколько преимуществ:

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

Недостатки Failed Event Manager (FEM) являются следствием его возможностей. В частности, используя FEM, невозможно передать сбойное сообщение другому адресату или изменить тип бизнес-объекта. Это приложение - "черный ящик", который в данный момент не предоставляет точек расширения для настройки.

Любая инструментальная программа MQ страдает из-за своей независимости от Process Server. Исследование причины сбоя может быть затруднено из-за необходимости поиска информации об ошибке, не присоединенной к MQ-сообщению. Данные сообщения редактируются в "необработанном" (raw) формате, что имеет свои "за" и "против" - у вас есть безграничные возможности для изменения всего, что содержится в сообщении, но существует риск создания некорректного формата сообщения. Редактирование сообщений, использующих модель нетекстовой сериализации (например, Java-сериализация) в "необработанном" формате, приводит к возникновению практически непреодолимых проблем. В таблице 2 показаны отличия инструментальных средств восстановления для MQ- и SIB JMS-сообщений.

Таблица 2. Сравнение инструментальных средств восстановления сбойных сообщений в MQ и SIB

Функциональная возможностьMQSIB

Доступ к информации об исключительной ситуации

Недоступен

Предоставляется

Все форматы, атрибут за атрибутом

Изменение типа данных

Возможно

Невозможно

Повторная передача

Выбор очереди вручную

Автоматически в исходную очередь

На практике восстановление MQ-сообщений в работающих системах, вероятно, потребует определенной автоматизации посредством сценариев.

Failed Event Manager - это инструментальная программа для восстановления SIB-сообщений, которые не могли быть обработаны. FEM MDB прослушивает очередь аварийных событий и регистрирует сообщение в базе данных FEM.

Failed Event Manager - это самое мощное средство восстановления в наборе программ WebSphere Process Server. Для доступа к FEM зарегистрируйтесь в WebSphere Process Server Integrated Services Console и выберите Integration Applications => Failed Event Manager, как показано на рисунке 5.

Рисунок 5. Обращение к Failed Event Manager

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

Рисунок 6. Исследование события в Failed Event Manager

Можно также просмотреть события Common Base Events, связанные с сообщением. Также можно изменить содержимое сообщения и повторно передать его.

Рисунок 7.

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

Независимо от используемого типа механизма активизации, стиль взаимодействия между каждым из SCA-компонентов в модуле может быть синхронным или асинхронным. Синхронная активизация компонента реализуется как Java-вызов. Асинхронная активизация влечет за собой помещение сообщения в SIB-адресат, ассоциированный с целевым компонентом, из которого сообщение извлекается SCA MDB-компонентом, и затем активизируется класс реализации компонента. Для настройки предпочтительного стиля взаимодействия для каждого SCA-компонента используется панель Details страницы Properties (см. рисунок 8). SCA-компонент активизируется асинхронно, если поле preferred interaction style установлено в значение Asynchronous, и синхронно, если это поле установлено в значение Synchronous или Any.

Рисунок 8. Указание предпочтительного стиля взаимодействия в интерфейсе модуля export

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

Листинг 1. Переопределение предпочтительного стиля взаимодействия во время исполнения
public void induceErrorOnOneWay(DataObject msg) { boolean useAsync = msg.getBoolean("dispatchAsynchronously"); OneWayErrorInducer service = locateService_OneWayErrorInducerPartner(); if (useAsync) { // Будет использоваться ASYNC-активизация OneWayErrorInducerAsync asyncService = (OneWayErrorInducerAsync)service; asyncService.induceErrorOnOneWayAsync(msg); } else { // Будет использоваться SYNC-вызов service.induceErrorOnOneWay(msg); } }

Асинхронная активизация может происходить между компонентами в SCA-модуле независимо от типа связывания модуля. Сервис, предоставляемый модулем, может быть активизирован синхронно (например, используя вызов Web-сервиса по HTTP); однако некоторые активизации внутри модуля могут быть асинхронными. Такие активизации разбивают транзакцию на части "до" и "после". Когда достигается граница асинхронного вызова, система времени исполнения SCA пытается поместить сообщение в SIB-очередь целевого компонента. Если операция проходит успешно, выполняется фиксация всей предыдущей работы. Вся работа, выполненная до этого момента, не отменяется и не повторяется, даже если системная ошибка возникает позже во время обработки запроса сервиса.

Затем целевой компонент выбирает сообщение из SIB-адресата. Если возникает ошибка, сообщение откатывается назад компонентам SIB-очереди до такого числа раз, какое указано в параметре "Maximum Failed Deliveries". После этого сообщение помещается в очередь Failed Event Manager. Такое сообщение можно восстановить, но это часто непрактично из-за недолговечности синхронных вызовов. Если сервис имеет двунаправленный интерфейс (запрос-ответ), компонент, инициировавший асинхронный вызов, вероятнее всего, завершился бы по тайм-ауту, прежде чем можно было бы восстановить сбойное сообщение вручную. Это привело бы к возврату аварии исходному инициатору синхронного вызова. Если увеличить таймаут асинхронных вызовов в SCA-модуле, исходный клиент сервиса, вероятнее всего, сам завершится по таймауту. По этой причине наилучшим действием в отношении сбойных сообщений в FEM, источниками которых являются синхронные интерфейсы, является удаление таких сообщений. В общем, асинхронные участки в синхронных запросах просто не предназначены для восстановления.

На рисунке 9 показана подробная информация об обработке сообщения в Process Server и некоторые сценарии восстановления.

Рисунок 9. Маршрутизация сообщений при сбое в компоненте

JMS/MQ-сообщение в SCA-модуле передаются как десериализованный бизнес-объект. Когда сообщение достигает JMS- (или MQ-) очереди, оно доставляется целевому компоненту следующим образом:

1. Сообщение извлекается JMS MDB компонента Export, использующего сервис прослушивателя.
2. После завершения десериализации и выбора функции JMS MDB должен поместить сообщение в SIB-адресат для извлечения компонентом SCA MDB; однако по соображениям производительности, когда сообщение доставляется из очереди адресата в целевой компонент, MDB-цепочка от JMS MDB до SCA MDB пропускается при первой попытке отправить сообщение. JMS MDB напрямую передает сообщение в целевой компонент.
3. В такой ситуации при возникновении ошибки в целевом компоненте сообщение откатывается назад в JMS MDB.
4. JMS MDB возвращает сообщение в исходную очередь (JMS/MQ-очередь или SIB-адресат исходного компонента).
5. В зависимости от установленного значения максимального числа повторов для очереди, доставка сообщения повторяется. На это раз JMS MDB передает сообщение в SCA-адресат для извлечения SCA MDB-компонентом.
6. SCA MDB отвечает за доставку сообщения в целевой компонент.
7. При возникновении сбоя сообщение откатывается назад в SIB-адресат. MDB пытается доставить его столько раз, сколько указано в параметре Maximum Failed Deliveries, а затем удаляет из очереди.

Для синхронных сервисов часто непрактично восстанавливать эти сообщения по причине их недолговечности. Если сервис имеет двунаправленный интерфейс (запрос-ответ), компонент, инициировавший синхронный вызов, вероятнее всего, завершился бы по тайм-ауту, прежде чем можно было бы восстановить сбойное сообщение вручную. Это привело бы к возврату аварии исходному инициатору синхронного вызова. Если увеличить таймаут асинхронных вызовов в SCA-модуле, исходный клиент сервиса, вероятнее всего, сам завершится по таймауту. По этой причине наилучшим действием в отношении сбойных сообщений в FEM, источниками которых являются синхронные интерфейсы, является удаление таких сообщений. В общем, асинхронные участки в синхронных запросах просто не предназначены для восстановления. То есть, важные бизнес-транзакции лучше обслуживаются асинхронной моделью, которая способна обеспечить гарантированную доставку сообщений и имеет механизмы восстановления.

Инфраструктура общих событий (Common Events Infrastructure - CEI) помогает исправить проблемы доставки сообщений. Можно записать информацию о сообщениях по мере их прохода по SCA-компонентам и позже просмотреть эту информацию в CEI-браузере. Однако CEI не является инструментальной программой восстановления - ее нельзя использовать для редактирования или повторной передачи сообщений. Информация о сбое отделяется от исходного содержимого сообщения, то есть информация является частью другого CEI-события.

Можно определить Common Base Events для каждой операции интерфейса для компонентов, за исключением Export. Можно также указать объем информации, записываемой с каждым событием: None, Digest или Full.

Рисунок 10. Настройка CEI на запись всего содержимого события

Сохраненная информация зависит от типа события. Для полного содержимого при выборе событий Entry и Exit записывается содержимое бизнес-объекта. Для события Failure записывается информация о сбое (исключительной ситуации). Следовательно, для полного исследования сбоя компонента с использованием CEI нужно разрешить и настроить два типа событий для полного содержимого: Entry (для сбора данных сообщения) и Failure (для сбора информации об исключительной ситуации).

CEI-события можно просмотреть в приложении-браузере Common Base Events. Для доступа к нему зарегистрируйтесь в консоли Process Server Integrated Services Console и выберите Integration Applications => Common Base Events Browser.

Рисунок 11. Просмотр событий Common Base Events, сгенерированных SCA

Далее следует пример сценария простого сервиса Credit Service, использующего однонаправленный интерфейс для приема данных о сотруднике при помощи карты отображения и Java-компонента для возврата кредитного балла вместе с одобрением менеджера. Простой тестовый Java-компонент генерирует различные исключительные ситуации. Назначением этого примера является демонстрация различных возможных аварийных условий в SCA-модуле, для того чтобы вы четко представляли поведение системы при реализации восстановления. Модуль разрабатывался настолько простым, насколько это было возможным.

Можно использовать исходный код из раздела "Загрузка" для тестирования маршрутизации сообщений и восстановления с различными настройками MQ-очереди. Пример требует наличия WebSphere MQ Version 6.0.1 и WebSphere Process Server Version 6.0.2.

Для установки примера:

1. Создайте менеджер локальной очереди по умолчанию под названием QM_nyconst60is, прослушивающий порт 1414.
2. Используйте MQSC-сценарий в файле create_qs.txt для создания локальных очередей.
3. Импортируйте файл source.zip в WebSphere Integration Developer V6.0.2 или выше как Project Interchange.
4. Измените MQ_INSTALL_ROOT для указание пути установки WMQ, как описано в технической рекомендации "java.lang.NoSuchFieldError: msgToken error occurs when trying to send message from WebSphere Application Server V6.0 to a WebSphere MQ V6 queue" на http://www.ibm.com/support/docview.wss?uid=swg21221195.
5. Используйте функциональные возможности Test Component или Test Module для тестирования компонентов в модуле MessageSender. Если установить атрибут сообщения shouldFail, имеющий тип boolean, в значение true, Java-компонент в принимающем модуле будет генерировать RuntimeException. Атрибут dispatchAsynchronously можно использовать для выбора синхронного или асинхронного стиля взаимодействия модулей.

Авторы хотели бы поблагодарить А. Ароноффа (AJ Aronoff), Джонатана Мачулеса (Jonathan Machules) и Дэви Гупта (Devi Gupta) за их помощь в написании этой статьи.

При возникновении системной ошибки в асинхронном SCA-сервисе сбойное сообщение не теряется. Знание того, куда направляется это сообщение, поможет выполнить восстановление после сбоя и завершить асинхронный запрос сервиса. Для сообщений, которые доставляются посредством WebSphere SIB JMS, программа Failed Event Manager предоставляет соответствующие возможности для исследования и восстановления. Если сообщение доставляется напрямую из WebSphere MQ, полное восстановление потребует использования пакета MQ support pack, другого программного обеспечения для администрирования MQ или специального сценария.

ОписаниеИмяРазмерМетод загрузкиПример кода в формате Proj Interchangesource.zip41 КБHTTPMQSC-сценарий для создания примеров очередейSIB_ME_stopped.zip3 КБHTTPПример трассировки стекаcreate_qs.zip1 KBHTTP

Иван Смирнов (Ivan Smirnov) - старший консультант Prolifics. Он работает с WebSphere Application Server и родственными продуктами с 2000 года. Иван с удовольствием совмещает функции разработчика и администратора, полагая, что это обеспечивает уникальный опыт в обеих областях. В настоящее время занимается SOA-проектами, в которых используются WebSphere Integration Developer и WebSphere Process Server.

Неха Дхавале (Neha Dhawale) - консультант Prolifics. Имеет опыт работы с различными продуктами WebSphere, например, WebSphere Application Server, WebSphere Process Server, WebSphere Integration Developer и MQ. Начав с J2EE-разработчика, Неха помогает нескольким клиентам реализовать сервис-ориентированную архитектуру с использованием различных продуктов Business Integration. В настоящее время занимается WebSphere Process Server.

Помощь по сообщениям о нарушениях

Спасибо. Эта запись была помечена для модератора.

Помощь по сообщениям о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.

developerWorks: вход

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

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

Выберите ваше отображаемое имя

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

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

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

SITE_ID=40

Zone=WebSphere

ArticleID=345467

ArticleTitle=Восстановление после сбоя активизации асинхронного SCA-сервиса на WebSphere Process Server

publish-date=10132008