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