Интеграция приложений на основе WebSphere MQ

"Вечный двигатель"


Этот прием весьма полезен при тестировании интерфейсов для проверки стабильности и надежности работы программ. Схема "вечного двигателя" изображена на рис. 7.12. В очереди Remote Queue rq1 на сервере WindowsNT в качестве параметра Remote Queue Name указывается rq2, а на сервере HP_UNIX в очереди Remote Queue rq2 соответственно rq1.


Рис. 7.12.  "Вечный двигатель"

И еще один прием, точнее святая обязанность администратора WebSphere MQ, это документирование интерфейсов. Весьма удобно иметь документированные интерфейсы в графическом виде, и программных средств для этого более чем достаточно (Visio, Bpwin и т.д.). Но по мере сложности интерфейсов их графическое представление становится не наглядным. В этом случае может быть рекомендован Excel, с помощью которого в колонках таблиц прописываются параметры настройки интерфейсов.

По мере возрастания количества интерфейсов, менеджеров и их объектов может возникнуть ситуация, когда администратор WebSphere MQ по названию объекта не сможет определить его сущность. Во избежание этого рекомендуется с самого начала разработать некоторые правила, по которым следует называть все объекты на разных менеджерах. Например, если простые локальные очереди (local queue) будут оканчиваться на .Q, трансмиссионные (transmission queue) на .TQ, локальные удаленные (remote queue) на .RQ, каналы на .CH, процессы на .P и так далее, то по окончанию сразу можно определить тип объекта. То же касается направления передачи и сущности передаваемых сообщений. Например, надо передать курсы валют из системы ABS1 в систему ABS2.

Создаваемые объекты в системе ABS1 можно назвать:

ABS1_ ABS2_CV.RQ – локальная удаленная очередь;

ABS1_ ABS2_CV.TQ – локальная трансмиссионная очередь;

ABS1_ ABS2_CV.CH – канал отправитель.

В системе ABS2:

ABS1_ ABS2_CV.Q – локальная очередь;

ABS1_ ABS2_CV.CH – канал получатель.

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


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

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

Серверное оборудование – чем мощнее сервера, тем быстрее будет работать программное обеспечение.

Размеры баз данных – чем больше база, тем дольше выполняются запросы.

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

Программное обеспечение – корректно написанная программа работает быстрее, к тому же выбор языка программирования играет важную роль. Замечено, что один и тот же алгоритм, реализованный на C и Visual Basic, дает существенно разные результаты. Например, простое перекладывание persistent сообщений размером 1Кб из очереди в очередь на одном и том же менеджере (NT платформа, процессор Pentium IV с тактовой частотой 1.8 ГГц) с помощью программы, написанной на С, дает результат 400 сообщений в секунду, а с помощью программы на Visual Basic только 140.

Тип хранения сообщений в очереди – сообщения persistent обрабатываются медленнее, чем not persistent. Not persistent сообщения из предыдущего примера перекладывались со скоростями 1000 и 200 сообщений в секунду, соответственно.

Наличие механизмов шифрования и сертификации также влияет на скорость обработки сообщений. Так использование SSL механизма может отнять до 10% производительности в зависимости от длины ключа и алгоритма шифрования данных.


Содержание раздела