Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iot-wg] IoT Connector project proposal
Hi Julien,

Actually using request/reply pattern with messaging systems is pretty common and works well for this kind of scenarios. It is only the matter of an extra latency added because device read request is now send from end-client to LeshanServer through AMQP instead of calling it directly. However this kind of latency is usually really small, as your massaging infrastructure deployed in a data center or cloud is usually very fast. I've been working with customers using our messaging technologies for a while and honestly I don't recall a single situation when messaging request/replay latency was an issue. 

As I understand with an architecture proposed by Kai we would have an end-client (like end-customer project willing to read device data) sending AMQP request/reply to Leshan wrapped as LWM2M protocol adapter. Adapter is able to receive the AMQP request, executes something like "leshanServer.send(client, new ReadRequest(resource))" and sends the AMQP response back to end-client. That would be really fast operation.

Keep also in mind that AMQP offers brokerless communication. With open source technologies like Apache Qpid Dispatch Router [1] you can connect two AMQP clients directly without the "broker middleman". That form of message exchange is extremely fast.

So I wouldn't be so concerned about using AMQP request/reply.

Cheers!

[1] http://qpid.apache.org/components/dispatch-router/

pt., 27.11.2015 o 18:15 użytkownik Julien Vermillard <jvermillard@xxxxxxxxx> napisał:
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,
when the device is there ask it's version,
wait for the response,
send the firmware download operation for the binary patch corresponding to the received version,
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).
If you put the state machine between the protocol adapter and the bus it will work, if you expect to put this logic on the northbound it won't.

Sending telemetry data from the device to a database or a rule engine in an async way is easy (even if it's where you probably have a lot of data).
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 :)

--
Julien Vermillard

On Fri, Nov 27, 2015 at 3:48 PM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
Hi,

we have created a draft version of a proposal [1] for starting a project under the Eclipse IoT umbrella for creating the IoT Connector component which is a central part of the IoT Server Platform [2]. We would like to encourage all interested parties to review and comment on the proposal so that we can make sure to create something that will be useful :-)

Please feel free to add yourself to the list of interested parties if you would like to see the component become reality and/or would like to collaborate on its development.

[1] https://wiki.eclipse.org/IoT/IoTConnectorProposal
[2] https://wiki.eclipse.org/IoT/IoTServerPlatform

Mit freundlichen Grüßen/ Best regards
 
Kai Hudalla

Bosch Software Innovations GmbH
Schöneberger Ufer 89
10785 Berlin
GERMANY
www.bosch-si.de

Mobile +49 (151) 54336335 
Phone +49 (30) 726 112-145
kai.hudalla@xxxxxxxxxxxx
 
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn


_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg

_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg
--
Henryk Konsek
http://about.me/hekonsek

Back to the top