ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Telemetry / Low Latency Messaging / Everyplace » MQTT Cloud

Post new topic  Reply to topic
 MQTT Cloud « View previous topic :: View next topic » 
Author Message
schmun
PostPosted: Wed Apr 30, 2014 1:08 am    Post subject: MQTT Cloud Reply with quote

Novice

Joined: 03 Jul 2009
Posts: 24

Hi

I can not find documentation about to configure a "global" mqtt provider within my MQ infrastructure.
How is it possible that a msg published on QMGR1 is received by a subscriber on QMGR2 (with and without MQ-Cluster)?

Does anyone know a howto?

Thanks.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Apr 30, 2014 2:46 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Depends on what you mean.

You can configure an MQ topology however you want, with the caveat that you have made sure that publications sent to one queue manager are received by other queue managers. This is purely MQ pub/sub topology configuration, MQTT has nothing to do with the movement of messages.

You can then configure one or more MQTT telemetry daemons attached to one or more of those queue managers. Publications sent to any of those MQTT daemons will then be bridged to MQ, and sent to any queue manager that is set up to receive them. Those publications will also be delivered to any MQTT subscribers connected to that daemon.

So if qmgr1 and qmgr2 are connected to each other using MQ, and they can both see each other's publications and subscriptions using normal MQ pub/sub topology config, then a publication made to an MQTT daemon that is connected to qmgr1 will be received by any MQTT subscribers connected to a daemon connected to qmgr2.

But the two MQTT daemons will not ever directly talk to each other. They bridge between MQTT and MQ.

If you really want a global MQTT provider than can handle lots of volume, you should get a MessageSight appliance.

As an example, the topology described at http://www.ibm.com/developerworks/websphere/techjournal/1404_paris/1404_paris.html uses three queue managers, one hosting Message broker, and two redundant edge queue managers hosting MQTT daemons. the mobile application connects to one of the two MQTT daemons, and the Broker uses Publication node to ship messages over an MQ cluster, and administrative MQ subscriptions to receive messages using MQInput node.
Back to top
View user's profile Send private message
schmun
PostPosted: Wed Apr 30, 2014 3:02 am    Post subject: Reply with quote

Novice

Joined: 03 Jul 2009
Posts: 24

Hi Jeff

Thank you!
If MQTT is "only" the bridge from the clients to the pub/sub engine of the queuemanager, i know what i have to do... resp. i have to do nothing :-)
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Apr 30, 2014 3:10 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

schmun wrote:
Hi Jeff

Thank you!
If MQTT is "only" the bridge from the clients to the pub/sub engine of the queuemanager, i know what i have to do... resp. i have to do nothing


No. It's not.

The MQ Telemetry daemon is a full service pub/sub engine that fulfills all of the requirements of the MQTT protocol.

You can connect lots of clients to a single MQ Telemetry daemon, and not have any messages touch MQ at all.

It also bridges messages to the MQ pub/sub engine.

The MQTT protocol does not specify anything about connecting two pub/sub engines together. So there's no notion in the MQ Telemetry daemon of connecting it to another MQ telemetry daemon.

So if you want, somehow, more than one MQTT endpoint that shares the same topic tree and distributes messages to subscriptions across the endpoints, then you can bridge to MQ.

But again, MessageSight is more robust, manageable and feature-rich. You don't need more than one MQTT endpoint, because a single appliance will handle *large* volumes. And bridge to MQ on the back end. (there's an HA option, as well).

You can download the MessageSight virtual appliance as a developer edition, and play around with it yourself.
Back to top
View user's profile Send private message
schmun
PostPosted: Wed Apr 30, 2014 3:42 am    Post subject: Reply with quote

Novice

Joined: 03 Jul 2009
Posts: 24

OK. Thank you again.
atm i am only playing with mqtt to see benefits within our existing large mq infrastructure. i have no demand of a project to use mqtt within an application.
my first idea is a loose event-moitoring in different firewall seperated network zones which have all a queuemanager included.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Telemetry / Low Latency Messaging / Everyplace » MQTT Cloud
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.