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



              

Средства программирования и администрирования брокера сообщений - часть 3


Используя представление администратора Broker Administration, пользователь может назначать разработанные потоки обработки брокерам на исполнение, возвращать потоки обратно в состояние разработки и динамически распространять сделанные программистами изменения на уже работающие потоки. Через это представления администратор определяет общую топологию среды распределенных брокеров WebSphere Message Broker, которые могут физически функционировать на различных операционных системах, в частности WindowsNT/2000/XP, Linux, UNIX, OS/390(z/OS), а логически могут образовывать иерархически построенные коллективы брокеров. Представление отображает состояние действующих брокеров и потоков обработки. Администратор WebSphere Message Broker может активизировать или приостановить работу отдельного потока, а также выполнять трассировку потоков разработки. Наконец, в журнале брокера отражаются успешные или неуспешные административные операции WebSphere Message Broker. В отношении использования Message Broker Toolkit остается упомянуть о возможностях групповой разработки, персональных настройках среды и разграничении функций в соответствии с ролями.

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

Внутренняя работа каждого брокера Message Broker управляется специальным процессом-контролером. За взаимодействие с сервером конфигурации и ведение внутренних данных брокера и кэш-таблиц отвечает особый процесс - агент брокера.

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




Содержание  Назад  Вперед