Help on scenario validation
Francisco Lomas
We are validating an possible scenario of use for a solution, the
scenario is:
1. An financial entity has mini POS like devices, in which you can do
a lot of transactions
2. Those devices has a very low bandwidth because the geographical
situation, max is 64kbps.
3. Actually those devices use Windows CE
4. The actual communications model is Request/Response via TCP sockets
5. As any financial entity, it requires that as fast as possible
responses and reliable responses too, because they need to accomplish
with SLAs for certain external service providers (Example: Mobile
companies gives you only 6 seconds to rollback any transaction)
6. The Message Broker will be Websphere (MQ and MB 7)
I have worked a lot implementing ESBs, the idea of using MQTT was
proposed by another provider, but I really have doubts about it,
specially because the MQTT communications model is Publish/Subscribe,
so I don't understand how to implement the communications in this
scenario.
Well, please any advice, ideas, comments are more than welcome!
Nicholas O'Leary
MQTT has been used many times in POS scenarios just like you describe.
> 2. Those devices has a very low bandwidth because the geographical
> situation, max is 64kbps.
That is exactly the sort of constrained environment that MQTT is suited for.
> 6. The Message Broker will be Websphere (MQ and MB 7)
With MQ/MB 7 you can easily add the MQ Telemetry feature to provide
your MQTT connectivity.
> I have worked a lot implementing ESBs, the idea of using MQTT was
> proposed by another provider, but I really have doubts about it,
> specially because the MQTT communications model is Publish/Subscribe,
> so I don't understand how to implement the communications in this
> scenario.
The fact that MQTT is pub/sub should not be an inhibitor - but the
precise details of how you would implement a solution would depend on
the details of your requirements.
For device->server messaging, there are a two basic options:
1. The devices could publish to a common 'inbound' topic, with the
payload containing a device identifier
2. The devices could publish to their own dedicated topics (such as
inbound/<deviceid>/)
In either case, a flow could be defined in MessageBroker to forward
the message to the right destination in the ESB.
For server->device messaging, the devices could subscribe to their own
dedicated topics (the reverse of #2 above) - such as
outbound/<deviceid>
Again, a flow in MessageBroker could be defined to handle this mapping.
I can get you in touch with some the MQ guys to discuss further if
you're interested.
Regards,
Nick
On 22 February 2012 17:41, Francisco Lomas
> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt
locked
poiint to point interactions. These solutions include retail, energy
and utilities, smart home to name but a few One common pattern for
inbound messages (from the device to the broker) is to publish to a
common inbound topic but set up the broker so that the messages get
moved to a queue (this is achieved with a managed subscription with
MQ). The beauty of this pattern is you can now have multiple
consuming apps process the inbound messages and each message will only
be processed once. For out bound as Nick suggests a topic unique for
each device is common practise.
If security is important then techniques such as signing and sealing
messages is a good practise.
All the best
Dave
Francisco Lomas
ask some questions!
Francisco Lomas
broker, but of course I never wonder how to route the message back to
the correct device, and of course I need the typical broker flow
because a lot of apps will use the same flow!