СМ-Консалт
 

Работа с Web-сервисами в корпоративных SOA: Часть 8. Извещение Web-сервисов о наличии в бизнес-системе EAI разнородных SOA

Статьи Технологии разработки ПО SOA и Web-сервисы

Вступление

В Части 7 данной серии я рассказывала о том, почему пакет XML двоичной оптимизированной упаковочной спецификации (XOP) более эффективен, чем XML-анализаторы при обработке масштабных, раздутых Web-сервис в текстовом формате. Я также показала, как конвертировать их в модернизированный двоичный формат в многочисленных SOA.

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


Стандартизация сообщений

Когда системы становятся слабосвязанными, возникает потребность в стандартизации способа получения Web-сервисами сообщений в ответ на различные события. Уведомления для Web-сервисов (WS-Notification) удовлетворяют эту потребность, позволяя Web-сервисам получать прямые предупреждения по одной или нескольким темам. Если каким-либо Web-сервисам необходимо взаимодействие с объектами, не являющимися Web-сервисами, WS-Notification обеспечивает эти объекты посредническими службами, чтобы донести посреднические предупреждения до клиентских Web-сервисов. Объект может быть либо автономным издателем, ПО, либо интерфейсом для приложения EAI с другим издателем.

У уведомлений для Web-сервисов много функций, например, в управлении системами и устройствами, а также в промышленном применении, например, в электронной торговле. WS-Notification было разработано для работы со средой Web Services Resource Framework (WSRF), которая обеспечивает службу создания подписки для определенной темы. Тема в списке подписок должна совпадать с темой в предупреждении клиентского Web-сервиса.

Если основанные на XML Web-сервисы, в частности, производители, клиенты, посредники и подписчики содержат в больших количествах масштабные текстовые файлы, спецификация XOP должна обработать основанные на XML Web-сервисы. Необходимо также оптимизировать эти службы при помощи бизнес-правил – в противном случае службы будут не эффективны в использовании спецификаций WS-Notification.


Состав предупреждения для Web-сервисов WS-Notification

Семья документов WS-Notification включает: техническое описание Publish-Subscribe Notification for Web services, а также три нормативных спецификации:

  • WS-BaseNotification
  • WS-BrokeredNotification
  • WS-Темы
Рассмотрим каждую из них.

 

  • Уведомление Publish-Subscribe для Web-сервисов: Данная спецификация устанавливает цели и требования для семьи документов WS-Notification и включает в себя обеспечение безопасности.
  • WS-BaseNotification: Данная спецификация выставляет основные выполняемые функции, определяя NotificationProducers, NotificationConsumers, предупреждения и подписки. Она описывает процесс приостановки и возобновления подписок, а также контроля срока подписки. (Обратите внимание: NotificationProducers являются производящими Web-сервисами или производителями уведомлений. NotificationConsumers представляют собой потребительские Web-сервисы или клиентских уведомлений.)
  • WS-Темы: Данная спецификация позволяет подписке ассоциироваться с определенной темой или темами после того, как пользователь подписывается на NotificationProducer.
  • WS-BrokersNotification: Данная спецификация позволяет объекту, не относящемуся к Web-сервису, создавать издателя, который создает сообщения и рассылает их через особую посредническую службу (NotificationBroker).

Парадигма Предупреждения WS-Notification

Давайте посмотрим на WS-Notification с другой точки зрения. Рисунок 1 показывает треугольник, который я называю парадигмой WS-Notification NotificationProducer, NotificationConsumer и NotificationBroker. Он формирует основу для уведомления Publish-Subscribe для Web-сервисов.


Рисунок 1. Парадигма уведомления для Web-сервисов
Парадигма уведомления для Web-сервисов

Обзор

Как вы видите, парадигма начинается с Подписчика, подписывающегося на потребительский Web-сервис – внешний или внутренний – для получения уведомлений, например, о системных ошибках или об исчерпании ресурсов; Web-сервис сохраняет перечни подписок и просматривает их для того, чтобы согласовывать тему в перечне и тему в уведомлении. Вы можете изменить или удалить подписки автоматически или вручную, если возникнет необходимость.

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

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

Посреднический Web-сервис

Если подписка имеется на объект, не относящийся к Web-сервису, производственный Web-сервис создает издателя для распределения сообщений о системных ошибках данному объекту через особый посреднический Web-сервис. Если тема, на которую подписан клиентский сервис, отличается от темы, издаваемой посредническим Web-сервисом, вы можете конфигурировать ее, чтобы посредник направлял сообщения клиентского Web-сервиса в соответствии с определёнными правилами.

Если посреднические предупреждения, предназначаемые клиентским Web-сервисам, не имеют совместимого формата, посредник получает от потребителя сигнал тревоги. Более того, если посредник находит входящие сообщения от издателя в формате, не соответствующем раздаче, посредник посылает сигнал тревоги производственному Web-сервису, чтобы тот направил сообщение клиентскому Web-сервису.


Разнородные SOA

Разнородные Web-сервисы из различных SOA тоже можно регистрировать для получения такой же информации о системных ошибках. Производитель информации может посылать многочисленные сообщения для каждого зарегистрированного Web-сервиса в отдельных SOA или во всех их типах. Web-сервис (например, в SOA № 1) может зарегистрироваться у другого Web-сервиса (например, в SOA № 2) и получать информацию, используя третье лицо.

Из-за большого количества уведомлений, посылаемых Web-сервисам, производитель информации может поручить реализацию Предупреждения Web-сервисов одному или нескольким видам ориентированным на сообщения межплатформенного ПО (MOM). Можно также установить иерархию NotificationProducer, где каждый элемент может передавать собственные функции провайдерам MOM через различные SOA, а управляющий NotificationProducer располагается на вершине иерархии в SOA.


Триггеры предельной нагрузки

Процесс усложняется, когда используются накладывающиеся друг на друга парадигмы WSN, в результат чего может возникнуть перегрузка множественных SOA. Это может случиться даже после того, как Web-сервисы были оптимизированы с помощью пакета XOP. Для того, чтобы снизить вероятность перегрузок, разработайте пороговые величины, которые вы сможете использовать для определения создания уведомлений и конфигурирования, чтобы инициировать предупредительные извещения о приближении пороговых величин. Один из способов – установить пороговые величины на влияние двусторонней связи между тремя нормативными предупреждениями Web-сервисов. Пороговые величины в парадигме WSN могут различаться в разных направлениях между Web-сервисами. Когда пороговая величина приближается к предельной, посреднический Web-сервис посылает пороговое предупредительное извещение внешнему Web-сервису.

Вы также можете применить предупредительные пороговые величины к следующим категориям:

  • Время выполнения: Эта категория представляет собой максимальное время, которое Web-сервис может использовать для запроса или издания предупреждения.
  • Время доступа: Эта категория представляет собой максимальное время, которое Web-сервис может предоставить другому Web-сервису или объекту, для того, чтобы сделать запрос или издать предупреждение.
  • Web-запросы: Эта категория представляет собой максимальное количество Web-запросов, которое Web-сервис может получить и послать приблизительно в одно время.
  • Суммарная ширина полосы пропускания: Эта категория представляет собой суммарную величину, которую дают все полосы пропускания, так как различные полосы пропускания могут конкурировать друг с другом в рамках сети.
  • Загрузка уведомлений: Эта категория представляет собой максимальное количество уведомлений, которым может управлять каждая SOA.
  • Скорость уведомлений: Эта категория представляет собой максимальную скорость, с которой уведомления можно рассылать в течение установленного времени.

Заключение

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

Вы поймете, что, решив эти вопросы заранее, значительно облегчаете работу по предупреждению приложений Web-сервиса. Вы сможете воспользоваться семьей документов WS-Notification, чтобы разработать уведомления для клиентских, производственных и посреднических Web-сервис в различных SOA. Администраторам также будет значительно легче управлять и администрировать предупреждения системного уровня. В результате, они смогут определить, сколько приложений может использоваться для получения и отправления предупреждений без перегрузок системы.

23.02.2008

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта