Что нового в WebSphere Enterprise Service Bus V7

В данной статье рассматриваются новые и улучшенные функциональные возможности продукта WebSphere ESB V7 и связанного с ним инструментария WebSphere Integration Developer, включая информацию о связывании в транспортном протоколе, посреднические примитивы и управление политиками.

Каллум Джексон, инженер-программист, IBM

Каллум Джексон (Callum Jackson) - фотографияКаллум Джексон (Callum Jackson) с 2005 года работает инженером-программистом в отделе WebSphere ESB подразделения IBM Hursley Software Lab в Великобритании. До этого занимался программными сервисами в SOA-приложениях для телекоммуникационной отрасли. Связаться с ним можно по адресу callumj@uk.ibm.com.



17.09.2012

Введение

IBM® WebSphere® Enterprise Service Bus (здесь и далее – WebSphere ESB) позволяет интегрировать несовместимые системы, организуя обмен запросами и ответами между различными сервисами. Посреднические модули (mediation module), разработанные в WebSphere Integration Developer, инкапсулируют логику взаимодействия сервисов для развертывания в исполняющей системе WebSphere ESB. Внутри посреднического модуля сообщения могут пополняться, преобразовываться, регистрироваться и направляться другим поставщикам сервисов в зависимости от одного или нескольких посреднических примитивов, определяющих логику потока сообщений. Сами сообщения представляются в логической структуре, называемой Service Message Object (SMO). Ссылки на дополнительную информацию по архитектуре WebSphere ESB приведены в разделе Ресурсы в конце статьи.

В данной статье не рассматриваются и не описываются подробно все новые возможности и функции WebSphere ESB V7. В ней представлены лишь некоторые новые функциональные возможности WebSphere ESB V7, включая улучшения в информации о связывании в транспортном протоколе (transport bindings), посреднические примитивы (mediation primitives), посреднические шаблоны (mediation patterns) и управление политиками. Для эффективного использования статьи необходимо иметь определенный опыт работы с продуктом WebSphere ESB и базовые технические знания о его возможностях и функциях. Краткое изложение новых функциональных возможностей WebSphere ESB V6.2 приведено в статье Что нового в WebSphere ESB V6.2 (EN).

Поддержка нового транспортного протокола

В WebSphere ESB можно активизировать существующие сервисы через операции импорта, тогда как посреднические модули отображаются внешним приложениям при помощи операций экспорта. Импорт и экспорт можно ассоциировать с информацией о связывании в транспортном протоколе. До версии V7 поддерживались Web-сервисы, WebSphere MQ, Java™ Message Service (JMS), WebSphere MQ JMS, HTTP и Service Component Architecture (SCA).

EJB-связывание

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

Рисунок 1. Информация о EJB-связывании для экспорта
Рисунок 1. Информация о EJB-связывании для экспорта

Новой является возможность выбора типа EJB-связывания: совместимое с EJB 2.1 или с EJB 3.0. Кроме того, можно решить, как отображать EJB: как локальный интерфейс, удаленный интерфейс или как тот и другой. Завершить процесс помогает мастер (см. рисунок 2).

Рисунок 2. Конфигурация EJB-связывания для экспорта
Рисунок 2. Конфигурация EJB-связывания для экспорта

Связывание сообщений

Имеется несколько улучшений в связывании сообщений для JMS и WebSphere MQ:

  • Поддержка Failed Event Manager. В WebSphere ESB V6.2 был представлен Failed Event Manager (менеджер неудачных событий), позволяющий централизовано хранить и управлять неудачными сообщениями, отправленными асинхронно. В V6.2 JMS-связывание поддерживало Failed Event Manager, а в V7 эта поддержка была распространена на связывание WebSphere MQ.
  • Динамическое назначение ответа. JMS-связывание имеет встроенную возможность динамически генерировать новую очередь назначения (destination queue) для приема ответного сообщения, что обеспечивает дополнительную гибкость при принятии решения о том, какой подход к проектированию выбрать.
  • Поддержка WebSphere MQ Resource Adapter. WebSphere MQ-связывание было дополнено поддержкой WebSphere MQ Resource Adapter, что расширяет возможности восстановления после сбоев и распределения нагрузки.

Поддержка новых и улучшенных посреднических примитивов

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

Примитив Flow Order

Примитив Flow Order (очередность потока) был представлен в V7 для реализации детерминированной логики ветвления в посредническом потоке. До версии V7 порядок выполнения ветвлений в посредническом потоке, порядок выполнения этих ветвлений был не детерминированным. Примитив Flow Order позволяет упорядочивать логику ветвлений, создавая отдельные клеммы для каждого ветвления и соединяя их, как показано на рисунке 3.

Рисунок 3. Посреднический примитив Flow Order
Рисунок 3. Посреднический примитив Flow Order

Примитив Gateway Endpoint Lookup

В WebSphere ESB V6.2 была представлена функциональность Service Gateway (шлюз сообщений), и в рамках работы по реализации высокоэффективной поддержки шаблона Service Gateway был добавлен новый примитив, предназначенный для шаблонов маршрутизации в Service Gateway. Этот примитив концентрируется на поиске оконечной точки Web-сервиса и имеет три различных режима работы:

  • URL. Используется при наличии в конце URL уникального идентификатора, предоставляющего идентифицирующую сервис информацию, которую можно использовать в качестве маркера для определения адреса оконечной точки, куда нужно направить сообщение. В этом режиме работы конфигурационные данные сохраняются во встроенном хранилище конфигураций (дополнительная информация по этому шаблону приведена ниже в разделе "Proxy Gateway").
  • XPath. Позволяет указать XPath-выражение, разрешающееся в уникальный идентификатор одного из всех сервисов, для которых используется Gateway. Затем этот идентификатор можно использовать как маркер для определения адреса оконечной точки, в которую нужно направить сообщение. В данном режиме работы конфигурационные данные сохраняются во встроенном хранилище конфигураций (дополнительная информация по этому шаблону приведена ниже в разделе "Proxy Gateway").
  • Action. Каждый запрос Web-сервиса имеет определенное значение SOAPAction, и, если это разрешено, значение действия WS-Addressing. Согласно спецификации, это значение должно быть "идентификатором, уникально и однозначно определяющим семантику, заключающуюся в этом сообщении". Для каждого сообщения, проходящего через примитив, значение действия определяется из ServiceMessageObject, а в репозитарии WebSphere Service Registry and Repository выполняется поиск WSDL-портов, имеющих такое же значение Action. Аналогично примитиву Endpoint Lookup для этого режима поиска можно указать определенные пользователем свойства и классификации.
Рисунок 4. Примитив Gateway Endpoint Lookup
Рисунок 4. Примитив Gateway Endpoint Lookup

По умолчанию примитив настраивается в режим URL, и никакого дополнительного конфигурирования не требуется. Однако чаще всего нужно указывать Proxy Group, как описано ниже. Если настроен режим XPath, кроме конфигурации Proxy Group необходимо включать XPath-выражение. Наконец, если необходим режим Action, необходимым условием является взаимодействие с WebSphere Service Registry and Repository (здесь и далее WSRR), и, следовательно, имя экземпляра WSRR должно быть указано, если значение по умолчанию не подходит.

В общем случае внутри Dynamic или Static Service Gateway используется маршрутизация, основанная на действиях, тогда как режимы URL и XPath используются только в новом шаблоне Proxy Gateway, рассматриваемом ниже. Независимо от используемого метода поиска назначения альтернативные адреса и контекст поиска оконечной точки внутри ServiceMessageObject будут заполняться результатами поиска.

Примитив Message Validator

Примитив Message Validator позволяет выполнять проверку корректности всего объекта Service Message Object или его части согласно информации схемы. Кроме проверки корректности в соответствии со схемой интерфейса при возникновении любых условий через примитивы (например, примитив SetMessageType), эти условия также будут проверяться. В примере на рисунке 5 сообщение проверяется до преобразования. Если проверка завершается неудачно, поток останавливается, чтобы предотвратить все последующие сбои.

Рисунок 5. Примитив Message Validator
Рисунок 5. Примитив Message Validator

Примитив Policy Resolution

До появления политик посредничества (mediation policy) посредническим потоком можно было управлять только при помощи рекомендуемых свойств (promoted property). Любое свойство, рекомендованное из посреднического потока, является видимым в консоли администратора и может быть изменено с соответствующим изменением конфигурации потока. Любые подобные изменения рекомендованных свойств влияют на все потоки, ссылающиеся на них, и сохраняются постоянно в развернутом приложении до тех пор, пока значение не будет снова изменено в консоли администратора. В WebSphere ESB V6.2 любое свойство, которое может быть рекомендовано, можно также изменять в динамическом режиме посредством политики посредничества, но все изменения, возникшие в результате управления политикой, сохраняются лишь на протяжении текущей активизации потока.

Рекомендуемые свойства могут рассматриваться как точки изменчивости (points of variability) внутри любого посреднического потока, а для определения того, какие значения используются в этих точках изменчивости, применяются политики посредничества. Политики посредничества используют формат WS-Policy. Существует простое соответствие между концепциями, используемыми в WS-Policy, и определяемыми WebSphere ESB в рекомендуемых свойствах. Это позволяет создавать один посреднический поток, который меняется в зависимости от содержимого обрабатываемого сообщения.

В WebSphere ESB V6.2 документы политики посредничества прикреплялись только к представлениям SCA-модуля внутри WSRR. Нововведение в WebSphere ESB V7 – возможность расширить эту поддержку за счет прикрепления документов политики посредничества к целевым сервисам, что позволяет настраивать посреднический поток на основе сервиса, которому был направлен запрос. Примитив Policy Resolution имеет теперь три режима работы:

  • Module (модуль). Настройка по умолчанию (логика аналогична V6.2).
  • Target Service (сервис назначения). Возможность искать политики посредничества внутри WSRR на основе информации о сервисе назначения, указанной в ServiceMessageObject (автоматически заполняется примитивом Endpoint Lookup).
  • Intersection of Module and Target Service (пересечение модуля и сервиса назначения). Обеспечивает возможность запрашивать в WSRR информацию о политике посредничества, ассоциированную как с модулем, так и с сервисом назначения. Запрос будет успешен только тогда, когда можно найти стратегию посредничества, согласованную с обоими уровнями, позволяющую потоку найти соответствие политики как из модуля, так и из сервиса назначения.

Эти варианты показаны на рисунке 6.

Рисунок 6. Примитив Policy Resolution
Рисунок 6. Примитив Policy Resolution

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

Примитив SLA Check

В WSRR V7 в профиле Governance Enablement Profile появилась поддержка соглашений об уровне сервиса (Service Level Agreement), которая позволяет создавать соглашения между клиентами, посредниками и сервисами (в терминологии WebSphere ESB). Выражения соглашения приведены ниже.

Рисунок 7. Диаграмма классов SLA
Рисунок 7. Диаграмма классов SLA
  • Service Level Definition (SLD) (определение уровня сервиса). Предоставляет формальную спецификацию качества сервиса, используемую для отправки сообщений в сервис, и содержит ссылки на адресуемые оконечные точки сети.
  • Service Version (версия сервиса). Предоставляет формальное изложение возможностей сервиса, ссылаясь на ассоциированное SLD для функциональной и нефункциональной спецификации. Каждая Service Version может иметь идентификатор потребителя, использующийся при работе сервиса в роли клиента другого сервиса.
  • Service Level Agreement (SLA) (соглашение об уровне сервиса). Предоставляет формальную спецификацию зависимостей конкретной Service Version от других определенных сервисов. Эти зависимости представляются как SLA, имеющее зависимости от SLD. Несколько SLA можно ассоциировать с одной Service Version; тем самым с каждым SLA можно ассоциировать свой contextId для обеспечения выбора желаемого SLA.

В WebSphere ESB имеется три схемы работы между клиентом, посредником и провайдером. Ниже красным цветом выделены данные, отправляемые посредством примитива SLA в WSRR:

Рисунок 8. SLA между клиентом и посредником
Рисунок 8. SLA между клиентом и посредником
Рисунок 9. SLA между клиентом и провайдером
Рисунок 9. SLA между клиентом и провайдером
Рисунок 10. SLA между посредником и провайдером
Рисунок 10. SLA между посредником и провайдером

Примитив SLA mediation позволяет определять выражение проверки SLA, в которое должна входить оконечная точка и, при желании, контекст и/или идентификатор потребителя. Последней настройкой является имя реестра, идентифицирующее, какой WSRR должен использоваться для оценки проверки SLA.

Рисунок 11. Панель примитива SLA Mediation
Рисунок 11. Панель примитива SLA Mediation

Примитив Trace

Во время разработки посреднического потока может быть полезно вывести трассировочное сообщение в файл – либо в стандартный WebSphere ESB SystemOut.log, либо в отдельный указанный файл. Для разрешения этой функциональности в WebSphere ESB V7 был добавлен новый посреднический примитив Trace. Примитив имеет несколько свойств (см. рисунок 12).

Рисунок 12. Панель примитива Trace Mediation
Рисунок 12. Панель примитива Trace Mediation
  • Enabled. Аналогично другим примитивам предоставляет возможность разрешать или запрещать функциональность примитива. Свойство с возможностью рекомендации (promotable property).
  • Destination. Определяет местоположение, куда следует добавлять трассировочное выражение: Local Server Log (SystemOut.log), User Trace (UserTrace.log) или File (определенный пользователем).
  • File path. Определяет местоположение трассировочного файла, когда в поле Destination указано значение File.
  • Message. Определяет формат отслеживаемых сообщений: {0} = метка времени, {1} = идентификатор сообщения, {2} = имя посредника, {3} = имя модуля, {4} = сообщение, определяемое свойством root, {5} = версия SMO.
  • Root path. Xpath-выражение, идентифицирующее, какой раздел SMO должен быть сериализован в сообщение. Также может быть включен дополнительный пояснительный текст.

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

Примитив UDDI

Universal Description Discovery and Integration (UDDI) (универсальное описание, поиск и интеграция) – это стандарт публикации и поиска описаний сервисов в сети. Соответствие между концепциями WSDL и UDDI рассматривается ниже при обсуждении интеграции в WebSphere ESB V7. Ссылки на дополнительную информацию о UDDI приведены в разделе Ресурсы в конце статьи.

  • BusinessEntity. Предоставляет бизнес-информацию, содержит один или несколько BusinessServices.
  • BusinessService. Содержит техническое и бизнес-описание Web-сервиса и аналогичен WSDL Service.
  • BindingTemplate. Аналогичен WSDL-порту.
  • tModel. Определяет техническую спецификацию для сервиса. Не имеет прямой ассоциации с разделом WSDL, а порождается из его раздела интерфейса сервиса.

Примитив UDDI предоставляет первоклассную поддержку интеграции с UDDI-репозиториями, такими как WebSphere Application Server UDDI. Раздел details разрешает конфигурирование имени UDDI-реестра и информацию об ассоциированном запросе. Если поиск выполнился успешно, соответствующие разделы header и context SMO обновляются аналогично примитиву Endpoint Lookup. Есть три возможные политики совпадения:

  • Return first matching endpoint and set routing target (возвратить первую совпадающую оконечную точку и установить цель маршрутизации). Целевой адрес записывается в раздел headers, а любая релевантная информация о реестре, ассоциированная с этой оконечной точкой, записывается в Endpoint Lookup Context.
  • Return all matching endpoints (возвратить все совпадающие оконечные точки). Вся возвращенная информация об оконечных точках записывается в Endpoint Lookup Context, но в раздел SMO header не записывается никакой целевой адрес.
  • Return all matching endpoints and set alternate routing targets (возвратить все совпадающие оконечные точки и установить альтернативные цели маршрутизации). Аналогична рассмотренной выше, но поля target и alternative раздела SMO header заполняются.

Улучшения примитива Fail

В V7 был усовершенствован примитив Fail: добавлена поддержка динамической генерации сообщений в дополнение к доступному прежде статическому полю. Теперь можно указать сообщение об ошибке, используя следующие подстановки:

  • {0} – значение метки времени;
  • {1} – значение идентификатора SMO Message;
  • {2} – значение имени посредника;
  • {3} – значение имени модуля;
  • {4} – сериализованный раздел SMO, указанный в поле Root Path;
  • {5} – значение версии SMO.

Эти настройки показаны на рисунке 13.

Рисунок 13. Панель примитива Fail
Рисунок 13. Панель примитива Fail

WSRR Query API

До версии WebSphere ESB V7 было всего два механизма взаимодействия с WSRR - примитивы Endpoint Lookup и Policy Resolution. В WebSphere ESB V7 был добавлен новый API запросов, позволяющий создавать специальные запросы внутри специализированного посредника и отправлять их в WSRR, используя в то же время преимущества встроенного механизма кэширования. Полное руководство по API для интеграции с WSRR приведено в информационном центре WebSphere ESB.

Улучшения примитива Endpoint Lookup

Ранее примитив Endpoint Lookup поддерживал оконечные точки Web-сервисов и операции SCA-экспорта. В WebSphere ESB V7 была добавлена поддержка следующих протоколов:

  • Оконечные точки MQ.
  • Оконечные точки JMS (SIB, MQ и обобщенные).
  • Оконечные точки, основанные на SCA: MQ, JMS, Web-сервисы, SCA и HTTP.
  • Оконечные точки HTTP.

Расширенная поддержка в примитиве позволяет запрашивать один протокол, все протоколы или существующее поведение оконечных точек SCA и Web-сервисов, как показано на рисунке 14.

Рисунок 14. Панель примитива Endpoint Lookup
Рисунок 14. Панель примитива Endpoint Lookup

Поддержка Business Space для WebSphere ESB

Business Space – это Web-интерфейс, позволяющий управлять приложениями, установленными в системе. Основными пользователями интерфейса являются администраторы ИТ и решений, которые хотят управлять установленными приложениями. Он был введен в WebSphere ESB V6.2 и позволяет просмотреть развернутые SCA-модули. В V7 его возможности были улучшены путем включения управления стратегиями посредничества (Mediation Policies) и прокси-шлюзами (Proxy Gateways).

Поддержка Proxy Gateway

Версия WebSphere ESB V6.2 поддерживала создание Service Gateways, предоставляя значительную гибкость в создании множества возможных схем шлюзов (gateway pattern). Такая гибкость имеет побочный эффект увеличения времени разработки решения. В WebSphere ESB V7 добавлена новая схема под названием Proxy Gateway, предоставляющая более быстрый и уже полностью готовый к использованию алгоритм работы. Proxy Gateway позволяет создавать WebService Service Gateway со встроенной маршрутизацией и найденным WSDL, который можно использовать для генерирования клиентов. На рисунке 15 показана схема новой концепции Proxy Gateway.

Рисунок 15. Proxy Gateway
Рисунок 15. Proxy Gateway

Идентифицировано несколько поставщиков сервисов, которые отображаются через Gateway. Они логически объединяются в группу Proxy Group, являющуюся набором сервисов. Во время разработки Proxy Gateway устанавливается взаимосвязь с одной или несколькими группами Proxy Group. Для каждого сервиса группы Proxy Group в Proxy Gateway отображается соответствующий виртуальный сервис (Virtual Service), что позволяет автоматически перенаправлять запросы сервиса из виртуального сервиса в реальный; тем самым завершается формирование логики шлюза в компоненте посреднического потока.

Сразу после разработки Proxy Gateway в WebSphere Integration Developer и его установки в системе времени исполнения администратор ИТ/решений может зарегистрироваться в Business Space и просмотреть взаимосвязи между Proxy Gateway, Proxy Group и Virtual Services. На рисунке 16 показан виджет Proxy Gateway, который в начале загрузки отображает Proxy Groups и ассоциированные Proxy Gateways.

Рисунок 16. Виджет BusinessSpace Proxy Gateway, отображающий взаимосвязи между Proxy Groups и Proxy Gateways
Рисунок 16. Виджет BusinessSpace Proxy Gateway, отображающий взаимосвязи между Proxy Groups и Proxy Gateways

Выбор Proxy Group переключает виджет на отображение виртуальных сервисов, ассоциированных с Proxy Group, как показано на рисунке 17.

Рисунок 17. Виджет Proxy Gateway BusinessSpace, отображающий виртуальные сервисы в Proxy Group
Рисунок 17. Виджет Proxy Gateway BusinessSpace, отображающий виртуальные сервисы в Proxy Group

Поддержка Mediation Policy

Поддержка политик посредничества (Mediation Policies) в Business Space устраняет необходимость создания и удаления политик посредничества посредством WSRR-консоли. Business Space имеет три ассоциированных виджета:

  • Service Browser. Позволяет просматривать сервисы, импортированные в WSRR. Эти сервисы могут иметь подключенные политики посредничества, которые впоследствии будут принудительно выполняться системой времени исполнения.
  • Module Browser. Позволяет просматривать модули, установленные в системе WebSphere ESB.
  • Mediation Policy Administration. При выборе сервиса или модуля в соответствующем виджете (Module Browser или Service Browser) связанные с ними политики посредничества отображаются в виджете Mediation Policy Administration. Политики посредничества можно не только просматривать но и создавать и удалять политики.

Этот новый виджет предоставляет специальный интерфейс, исключающий большое количество стандартных действий WS-Policy, которые ранее были необходимы при использовании WSRR-консоли. Чтобы создать политику посредничества, пользователю интерфейса практически не требуется знание спецификации WS-Policy.

Рисунок 18. Виджет Module Browser BusinessSpace
Рисунок 18. Виджет Module Browser BusinessSpace
Рисунок 19. Виджет Service Browser BusinessSpace
Рисунок 19. Виджет Service Browser BusinessSpace
Рисунок 20. Виджет Mediation Policy Administration BusinessSpace
Рисунок 20. Виджет Mediation Policy Administration BusinessSpace

Администрирование и мониторинг расширений

В данном разделе рассматриваются новые возможности WebSphere ESB V7 в части улучшения функциональности управления и мониторинга.

Мониторинг сервисов с Business Space

Виджет Service monitoring в BusinessSpace измеряет время реакции и пропускную способность запросов, активизируемых и отображаемых SCA-модулем. Вы выбираете, мониторинг каких операций осуществлять в сервисах, отображенных инициаторам запросов (Exports) и потребляемых (Imports). Можно при желании определить граничные значения времени реакции и пропускной способности, реализовав тем самым полностью готовую к использованию функциональность мониторинга для SCA-модулей. На рисунке 21 приведен пример предоставляемой выходной информации.

Рисунок 21. Виджет Service Monitor в BusinessSpace
Рисунок 21. Виджет Service Monitor в BusinessSpace

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

Контроль работоспособности и обнаружение проблем с Business Space

Интегральной частью администрирования решения является слежение за работоспособностью всей системы, а также за работоспособностью административных артефактов в модуле, таких как запросы, механизмы обмена сообщениями, источники данных, серверы и кластеры. Виджеты Module and System Health предоставляют единый интерфейс для быстрой проверки состояния решения и для просмотра следующей информации:

  • какие приложения выполняются;
  • какие серверы в топологии запущены, остановлены или недоступны;
  • какая задана максимальная глубина очередей и насколько вы близки к пределу;
  • какие артефакты механизма обмена сообщениями работают;
  • все ошибочные события в модуле.
Рисунок 22. Виджет System Health в BusinessSpace
Рисунок 22. Виджет System Health в BusinessSpace

Cross-Component Trace

Функция Cross-Component Trace (межкомпонентная трассировка) позволяет отслеживать сообщения, проходящие через SCA-модули и компоненты. Она добавляет в стандартное устройство вывода трассировочные сообщения, которые анализируются программой просмотра в WebSphere Integration Developer. В WebSphere ESB V7 добавлена возможность отслеживать процесс прохождения сообщения через отдельные примитивы, а не только на уровне посреднических компонентов. Пример приведен на рисунке 23.

Рисунок 23. Межкомпонентная трассировка
Рисунок 23. Межкомпонентная трассировка

Установка очередности событий

До WebSphere ESB V7 установка очередности событий была ограничена системами времени исполнения WebSphere Process Server, но в V7 она включена в систему времени исполнения WebSphere ESB V7. Установка очередности событий позволяет компонентам WebSphere ESB обрабатывать события от асинхронных вызовов в том порядке, в котором они доставлялись. Порядок событий поддерживается во всем сценарии. В некоторых реализациях можно потребовать, чтобы компонент назначения обрабатывал события в том же порядке, в котором они были отправлены приложением-источником; обработка их не по порядку может вызвать появление ошибок или исключительных ситуаций. В подобных случаях можно выбрать опцию Event Sequence в асинхронных компонентах Export и SCA для включения этой возможности:

Рисунок 24. Включение функциональности задания очередности событий
Рисунок 24. Включение функциональности задания очередности событий

Ресурсы

  • Оригинал статьи What's new in WebSphere Enterprise Service Bus V7 (EN).
  • Что нового в WebSphere ESB V6.1 (EN)
    В статье рассматриваются новые и улучшенные функциональные возможности продукта WebSphere ESB V6.1 и связанного с ним инструментария WebSphere Integration Developer, включая информацию о связывании в транспортном протоколе, связывании данных, поддержке административных и посреднических модулей.
  • Что нового в WebSphere ESB V6.2, часть 1. Обзор (EN)
    В данной статье рассматриваются новые и улучшенные функциональные возможности продукта WebSphere ESB V6.2 и связанного с ним инструментария WebSphere Integration Developer, включая информацию о связывании в транспортном протоколе, связывании данных, посреднические примитивы и декларативное управление потоком. В первой части приводится обзор новых возможностей.
  • Что нового в WebSphere ESB V6.2, часть 2. Шаблоны Service Gateway (EN)
    Во второй части рассматриваются функциональные возможности Service Gateway и Service Policy продукта WebSphere ESB V6.2.
  • Освоение WSDL в UDDI-реестре (EN)
    В данной статье рассматриваются различные способы использования WSDL с UDDI-реестрами в зависимости от потребностей приложения.
  • Использование нового API WSRR в WebSphere ES
    Данная тема в информационном центре WebSphere Integration Developer посвящена выполнению запросов к Websphere Service Registry and Repository в примитиве Custom Mediation.
  • Страница продукта WebSphere ESB
    Описание продукта, новости, информация по обучению, поддержка и др.
  • Информационный центр WebSphere ESB
    Единый Web-портал со всей документацией по WebSphere ESB, включая концептуальную и справочную информацию по установке, настройке и использованию WebSphere ESB.
  • Библиотека документации по WebSphere ESB
    Руководства по использованию WebSphere ESB.
  • WebSphere ESB FAQs
    Основные вопросы и ответы о новом продукте WebSphere ESB и его взаимосвязи с другими продуктами WebSphere.
  • Поддержка WebSphere ESB
    База данных с возможностью поиска информации о проблемах поддержки и их решении, файлы для загрузки, пакеты исправлений, отслеживание проблем и т.п.
  • Redbook. Шаблоны: проектирование SOA с использованием WebSphere Message Broker и WebSphere ESB
    Шаблоны для электронного бизнеса – это проверенные активы многократного использования, которые можно применять для увеличения скорости разработки и развертывания приложений. В данном Redbook-руководстве рассказывается, как использовать WebSphere ESB вместе с WebSphere Message Broker для реализации ESB в SOA. Приводится сценарий, демонстрирующий проектирование, разработку и развертывание.

Комментарии

developerWorks: Войти

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


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


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

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

 


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

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

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



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=835385
ArticleTitle=Что нового в WebSphere Enterprise Service Bus V7
publish-date=09172012