У меня нет однозначного ответа, потому что я специализируюсь исключительно на WMQ.Тем не менее, я считаю, что ответ «нет» по большей части.(Подробнее об этом через минуту.)
Что касается WMQ, IBM предоставляет точки выхода для настройки поведения каналов, вызовов API и авторизаций.Выходы очень хорошо документированы и выполняют узкие функции в рамках определенного действия - т.е. принимают сообщение, инициируют соединение и т. Д. Они написаны на C и, совсем недавно, на Java.По большей части они не используются, и клиенты, с которыми я общаюсь, обычно ссылаются на сложность.Они хотят что-то настраиваемое через конфигурацию, а не через низкоуровневый код.Я подозреваю, что другие поставщики MOM испытывают аналогичные требования со стороны клиентов.
Какое отношение это имеет к вашему вопросу?Я полагаю, что если клиенты не хотят кодировать выходы с ограниченными функциями, кажется, что они надуманы, что они будут кодировать полнофункциональный и надежный клиент, который поддерживает надежную доставку сообщений, одно- и двухфазную фиксацию, клиент-побочные выходы, диагностика и все другие функциональные возможности, которые предоставляют каналы WMQ.
Предполагая, что эта задача была предпринята командой с открытым исходным кодом, способной на этот уровень кода, кто ее поддержит?поставщики MOM в настоящее время предоставляют сквозную поддержку при использовании своих проприетарных клиентов.Представление о том, как можно устранить проблему при использовании стороннего клиента, поддерживаемого сообществом, для многих клиентов немного пугает.Например, IBM поставляет дополнения для WMQ под названием SupportPacs.Хотя существуют SupportPac, которые полностью поддерживаются и считаются расширениями продукта, некоторые из SupportPac предоставляются как есть.Многие из моих клиентов не будут запускать код «как есть» , даже если он предоставлен поставщиком .
Наконец, существует понятие контракта интерфейса.WMQ поддерживает несколько глаголов с большим количеством опций.Базовый протокол канала НАМНОГО сложнее.Когда вышел WMQ v7, у каналов появился значительный новый функционал и настройка.это было возможно в таком масштабе, потому что внутренние устройства не были доступны клиентам, и поэтому IBM смогла внести значительные изменения, не опасаясь негативного влияния на сторонних клиентов.Раскрытие всего этого создаст зависимости на порядок или два выше, чем у существующего, только с открытым API.
Итак, согласно моей теории (я не претендую на то, чтобы выступать здесь за команду разработчиков MQ),поставщики крупных MOM заинтересованы в том, чтобы , а не раскрывали свои протоколы канала независимым разработчикам.Новая складка здесь - AMQP, о которой я говорил выше.Он определяет проводной протокол и позволяет каждому поставщику кодировать совместимый продукт.Хотя это предоставляет возможность, которую вы описываете для решений с открытым исходным кодом, способность любой реализации улучшить продукт ограничена тем фактом, что они не владеют протоколом.Хотя пока я не ожидаю, что вы найдете кого-либо из крупных поставщиков MOM, выставляющих свои проводные протоколы для сторонней разработки.Тем не менее, это всего лишь предположение, и если я ошибаюсь, я уверен, что кто-то здесь подскажет и предоставит контрпример.