Смотрю на мир и не перестаю удивляться. Есть два монстра по MB. Ну ладно один западник, до него не достучаться, но второй уже который год тусуется в российском IBMе, и практически всегда готов к пивным встречам J

Так вот со вторым всегда можно договориться он обязательно поможет, вот такой он человек. И ГЛАВНОЕ лучше него про Message Broker сказать никто не сможете, ну кроме Энди.

Так вот эта сладкая парочка уже давно пишет везде и повсюду как правильно создавать код под MB. Но наши системные интеграторы идут своим , небезопасным для клиента путем. Путем тернистым и дорогим.

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

Если вы планируете свою интеграцию перевести на MB то вы , как системный аналитик должны знать,что :

Execution Group, есть не что иное как отдельный экземпляр JVM. А значит, вы можете настраивать JVM по своему желанию

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

Не все можно написать на ESQL, но все можно написать на java. Я бы везде где возможно использовал именно java.

Если же вы уверены в действенности ESQL, так и укажите в ТЗ, что лучше использовать ESQL. Что бы у разработчика не было даже повода использовать другие языки.

Активно использовать заголовки сообщений . Прекратить пагубную практику разбирать тело сообщения и на основании разбора тела сообщений строить маршрутизацию.

В каждом потоке использовать строго определенный тип данных (по возможности). Лучше иметь несколько потоков с для каждого конкретного типа данных, чем одни универсальный для всех типов.

 Количество узлов в потоке должно стать минимальным, до разумных пределов.

Режьте, и не задумывайтесь. Большие сообщениям на сотни маленьких. И не занимайтесь понапрасну парсингом (разбирайте сообщение содержащие однотипные данные)

Максимально использовать функционал MQ. И переложить часть работы на плечи MQ.

Не забывайте про правильные настройки MQ.Вы сэкономите массу времени и денег если если ваши очереди будут правильно сконфигурированы именно для ваших потоков.

WAS прекрасно дружит с MB. Не забывайте об этой дружбе. При условии ,что вы используете WAS и вам действительно необходимо дружеское общение между товарищами.

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

Про глобальный кеш я уже писал . Пользуйте обязательно.

Лучше с базой данных общаться посредством хранимых процедур. Не придется 10 раз передеплоивать один и тот же flow с различными sql запросами.

Не ясна причина по которой системные аналитики подписывающие ТЗ для разработки на IB(MB) активно игнорируют советы двух уважаемых людей, тем самым ставя под удар успешность интеграционных решений.

Если больше половины из сказанного вам не понятно или у вас есть замечания , в IBM вам всегда помогут J.