Pub / Sub
До v7 WMQ Pub / Sub был доступен либо как отдельный компонент WMQ, либо как часть функциональности WebSphere Message Broker. Теперь в v7 pub / sub является неотъемлемой частью WMQ и обеспечивает безопасность на уровне темы. Существует определенное количество публикаций / подпрограмм, которые происходят только потому, что теперь они встроены в WMQ в качестве нативной функциональности.
Еще один фактор, влияющий на распространение в пабе / субмарине WMQ, заключается в том, что все больше людей получают доступ к нему через WMQ File Transfer Edition. WMQ FTE делает состояние передачи файлов доступным в виде публикаций, и многие люди, использующие этот продукт, пишут приложения, которые следят за этими темами, чтобы обеспечить различные пользовательские функции. Как только они начинают использовать pub / sub, многие из этих магазинов начинают искать другие варианты использования.
Pub / Sub также решает некоторые распространенные проблемы с обменом сообщениями, такие как приложение, которое в данный момент пишет в очередь, и возникает новое требование, чтобы получить копию этого сообщения другому потребителю. До v7 переключение приложения с записи в очередь на запись в тему было несколько инвазивным и требовало изменения конфигурации для приложений JMS или изменения кода для других типов кода. Самый простой способ решить проблему - перехватить сообщение с помощью приложения или выйти, который записал копии в две или более очередей. Начиная с версии 7 приложение, написанное для очередей, может быть снабжено псевдонимом по теме. Производитель все еще думает, что пишет в очередь, но вместо этого WMQ публикует сообщения в теме. Потребители могут либо подписаться напрямую, либо, в случае устаревшего кода, требующего очереди, административная подписка может привести к доставке сообщений по теме в очередь. Я вижу, что в пабе / сабе много внимания уделяется этим требованиям.
В некоторых случаях подходящим решением является pub / sub, и оно используется только по этой причине. В прошлом требования к отдельным компонентам, административным навыкам или лицензии WMB были барьерами для принятия, что приводило к тому, что определенная часть приложений паба / подпрограмм была переработана как точка-точка. Благодаря встроенному в WMQ pub / sub эти барьеры устранены или, по крайней мере, значительно уменьшены, что приводит к большему поглощению просто потому, что это правильная архитектура для рассматриваемой проблемы.
В целом, я бы сказал, что паб / саб WMQ стал популярным с v7. Поскольку в сентябре 2011 года было объявлено об окончании срока службы v6, массовая миграция на v7 в этом году и, как следствие, еще большее распространение pub / sub.
SSL / TLS
Что касается SSL, безопасность WMQ приближается к мейнстриму. Я бы не сказал, что SSL является нормой - пока что - но в последние два-три года он достаточно востребован, чтобы мои практические занятия по безопасности WMQ на конференциях IMPACT и European WebSphere Technical имели был переполнен посещаемости. Я недавно написал ...
Термин "доверенная внутренняя сеть"
был придуман, чтобы дифференцировать эту часть
сети, которая была внутренней от
Направления вне брандмауэра. Но
термин «доверенный», как используется в этом
контекст относительно. Не было
должен указывать, что внутренний
сети доверяли неявно, только
что ему доверяют больше, чем вещам
вне брандмауэра. К несчастью,
термин иногда интерпретируется
в буквальном смысле. У меня были клиенты
довольно серьезно скажи мне по определению
мы доверяем всему на "доверенных
внутренняя сеть ", поэтому мы называем
это то. Конечно, это завышает
дело, потому что даже самый верный
верующие в доверии внутреннему
сеть все еще применяет пароли
вход на серверы, базы данных и
Приложения. Так что внутренняя сеть
доверяют, но только до определенного момента,
и даже во внутренней сети
аутентификация и авторизация
необходимо.
Хотя каналы SSL (фактически TLS) шифруют, они также аутентифицируются.По мере того, как все больше людей осознают, что им необходимо аутентифицировать соединения WMQ в «доверенной» внутренней сети, SSL является распространенным методом достижения этого.Разумеется, растет и потребность в услугах конфиденциальности (шифрования) и целостности каналов WMQ для внутренних и внешних подключений, что также способствует внедрению каналов WMQ SSL.
Теперь, когда SSL стал болееОбычно возникает ряд второстепенных проблем, когда люди не до конца понимают безопасность WMQ.Тот факт, что сейчас это общие темы в WMQ listserve и MQSeries.net , свидетельствует об уровне принятия SSL.Некоторыми из этих вторичных проблем являются включение неиспользуемых корневых сертификатов Центра сертификации в хранилище ключей QMgr или отсутствие настроек канала QMgr, таких как SSLPEER (который фильтрует соединения по различаемому имени) или MCAUSER (который сопоставляет полномочия определенной учетной записи пользователя).Часто люди включают SSL, но пропускают один или несколько из этих других параметров и не достигают того уровня безопасности, который они планировали.Поскольку вы, должно быть, включили SSL, чтобы эти вещи представляли проблему, он, как сказал мой друг, «проблема роскоши».Гораздо лучше бросить вызов настройкам SSLPEER, чем вообще не применять SSL.
В итоге ...
Так что я предполагаю краткий ответ на оба эти вопросаявляется то, что использование pub / sub и SSL в WMQ довольно распространено.Сейчас оба имеют тенденцию к резкому росту, и если бы я писал новые приложения, я бы определенно использовал SSL и без колебаний использовал бы WMQ pub / sub там, где это было необходимо.