как я могу отправлять сообщения в/из брокера сообщений Websphere из встроенного клиента C (без JVM)?

Каковы мои варианты для публикации сообщений (или точка-точка, но pubsub лучше) сообщений от брокера сообщений IBM и от встроенного безголового клиента C/C++ linux, у которого нет JVM?

В идеале нам нужна передача больших файлов (2 ГБ один раз в день вне клиента), шифрование (SSL), надежное («гарантированная» доставка / QoS2, возможно, QoS1 подойдет)

У рассматриваемого клиента в настоящее время есть только исполняемые файлы и некоторые скрипты bash, я играл с MQTTv3 и RSMB, но для этого мне пришлось бы пережевывать большие файлы (и собирать их дома), и я не хочу получать в это, если есть транспорт, который сделает это для меня?

Я просмотрел MQTTv5 (но у нашего клиента нет JVM); JMS (без JVM) и XMS? который снова выглядит так, как будто он дает мне C API, но затем требует установки JVM на клиенте (или я ошибаюсь?)

любые подсказки или подсказки будут оценены, ура


c++ publish-subscribe websphere ibm-mq messagebroker
person timB33    schedule 15.02.2010    source источник
comment
я должен смотреть на XMPP, AMQP или STOMP? они звонят в колокола? Я думаю, что мой вопрос может быть просто связан с тем, какой транспортный протокол я должен использовать для надежной и безопасной публикации файлов размером 2 ГБ от клиента только c к любому брокеру сообщений, который может подключаться к WMB?   -  person timB33    schedule 15.02.2010

Ответы (2)


arrow_upward
1
arrow_downward

Почему бы просто не использовать API WMQ C/C++? Установку клиента WMQ можно загрузить как SupportPac MQC7: клиенты WebSphere MQ V7.0. После этого просто использовать C API и компилировать как обычно. Это все родные функциональные возможности базового продукта WMQ.

Обратите внимание, что WMQ V7 QMgr с клиентом WMQ v7 обеспечивает намного лучшее взаимодействие с JMS, WMQ Broker и т. д., поскольку все атрибуты сообщения теперь являются свойствами сообщения, а публикация/подписка изначально поддерживается в WMQ v7 QMgrs. . Кроме того, в сентябре 2011 года срок службы версии 6 истек, поэтому сделайте как можно больше новых разработок для компонентов версии 7, чтобы избежать миграции в будущем.

person T.Rob    schedule 27.04.2010

arrow_upward
1
arrow_downward

Вы говорите об одном/нескольких крупных переводах или о большом количестве более мелких переводов? Это говорит о потребностях вашего решения даже больше, чем о том, какое необработанное подключение.

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

  1. отправляйте данные с помощью родного (или любого другого) приложения в Linux в назначенное место с использованием SCP или HTTPS или эквивалентного, в основном просто публикуя данные.

  2. иметь поток МБ, который может обрабатывать данные вперед.

Если это множество небольших вызовов, почему вы не можете сделать это через узел HTTP[S] в качестве главы вашего потока данных MB? Обработка и отправка данных в нативное приложение с помощью HTTP POST не должна быть такой сложной, и должно быть много уже существующего «искусства», чтобы дать вам преимущество.

person ted_j    schedule 01.03.2010
comment
Это большой файл один раз в день и множество отдельных маленьких пабов в остальное время. Ура, я слышу, что вы говорите (и я поставил вам +1), поскольку ваше решение было тем, которое мы изначально планировали, однако ... от нас требуется использовать сквозную передачу сообщений, мы в настоящее время идет с RSMB в комплекте, пережевывает большой файл, а затем собирает его на отдельном ПК, на котором установлена ​​JVM, а затем отправляет его за один раз в Websphere. - person timB33; 08.03.2010
comment
Спасибо. Я полностью слышу вас по поводу этих внешних требований. Они, безусловно, достаточно часто приводят наши реализации в странное русло. Иногда они имеют смысл, иногда нет. Надеюсь, ваша система будет просто красивой и стабильной. - person ted_j; 08.03.2010