| Re: [iot-wg] IoT Connector project proposal |
|
Hi Julien, I am really glad that you find some interest in discussing the IoT Connector and the underlying idea of the IoT Server Platform. The experience
you gained from your work in these fields will be a valuable resource J I think that you are right with your point regarding the need for supporting interactions more complex like plain telemetry data transmission.
However, I do not quite understand why you think that the scenario sketched out by you would not be possible with the business/orchestration logic located on the northbound side of the IoT Connector. wait the device to connect, // Protocol Adapter sends out a corresponding event via the IoT Connector wait for the response, // wait for response message received via IoT Connector
poll the download status // send read requests polling download status etc.
(via IoT Connector and Protocol Adapter) While I agree that the IoT Connector will introduce some amount of latency to each interaction, I cannot see why this amount of latency (I’d assume
we are talking up to hundreds of milliseconds) would prevent the scenario to be successfully implemented. On the other hand, introducing the IoT Connector to a cloud based IoT infrastructure has a lot of advantages as Henryk has already elaborated on
… Regards, Kai From: iot-wg-bounces@xxxxxxxxxxx [mailto:iot-wg-bounces@xxxxxxxxxxx]
On Behalf Of Julien Vermillard Hi Kai, first question: Scenario for complex operation like firmware upgrade or device configuration are in the scope? Because if I read between the line an async queue based architecture won't be able to handle very synchronous operation like: wait the device to connect, wait for the response, poll the download status if you put an async construction like rabbitmq between the device protocol gateway and something implementing this scenario it won't work because the device will probably left when you will unqueue the next event and you need to send the
next command before the device is gone. You can't enqueue whole command at once because you have control flow (loop and if).
Command flow control is a totally different beast, it needs synchronous behaviour. You can try to use your bus/RabbitMQ in a synchronous way (RPC style constructions with ephemeral response queue) but a good old database will be a better choice. I hope it does make sense :)
-- On Fri, Nov 27, 2015 at 3:48 PM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote: Hi, |