Re: [ditto-dev] Support for MQTT in ditto-client

[Julian Feinauer <j.feinauer@xxxxxxxxxxxxxxxxx>]

Hi Thomas,

 

I agree with everything you say : )

We also switched to HiveMQ in all our stuff and the complete API of the client is already nicely set out for Async operations.

 

And yes, I played a bit with MQTT Messages in a local set up and experimented a bit with the “header” section.

This makes it (from my perspective) even more important to abstract it away behind a Client to hide it away from the User who should not care about that kind of stuff.

 

Julian

 

Von: <ditto-dev-bounces@xxxxxxxxxxx> im Auftrag von "Jaeckle Thomas (INST/ECS1)" <Thomas.Jaeckle@xxxxxxxx>
Antworten an: ditto developer discussions <ditto-dev@xxxxxxxxxxx>
Datum: Mittwoch, 15. Januar 2020 um 10:58
An: ditto developer discussions <ditto-dev@xxxxxxxxxxx>
Betreff: Re: [ditto-dev] Support for MQTT in ditto-client

 

Hi Julian.

 

Adding MQTT as additional channel / MessagingProvider to the Ditto client totally makes sense.

We already abstracted the MessagingProvider as interface for such additions:

https://github.com/eclipse/ditto-clients/blob/master/java/src/main/java/org/eclipse/ditto/client/messaging/MessagingProvider.java

 

So it should be possible to implement a MQTT based MessagingProvider in addition to the WebSocket one:

https://github.com/eclipse/ditto-clients/blob/master/java/src/main/java/org/eclipse/ditto/client/messaging/internal/WebSocketMessagingProvider.java

 

A few additional thoughts:

• As MQTT 3.1.1 has no support for headers, setting something like a “reply-to” address (required for getting responses when sending commands from the client to Ditto) or a “correlation-id” must be all part of the payload JSON (as “header” section in the Ditto Protocol, but this should already work)
• Please use the HiveMQ MQTT client – and also the async API of that – because we already use that as well in the Ditto backend and don’t want to support another MQTT client J

 

Would be great if you or your bachelor thesant starts working on this.

 

 

Mit freundlichen Grüßen / Best regards

Thomas Jaeckle

Engineering Cloud Services 1 Bosch IoT Things (INST/ECS1)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

From: ditto-dev-bounces@xxxxxxxxxxx <ditto-dev-bounces@xxxxxxxxxxx> On Behalf Of Julian Feinauer
Sent: Mittwoch, 15. Januar 2020 08:18
To: ditto developer discussions <ditto-dev@xxxxxxxxxxx>; Musti El-Sari <musti-@xxxxxxx>
Subject: [ditto-dev] Support for MQTT in ditto-client

 

Hi all,

 

in my example for plc4x and ditto I used the ditto-client project as its awesome, easy and typesafe handling of ditto json messages.

But as discussed in Gitter for a real world example the transport from the edge gateway next to the PLC to the ditto instance should happen over some kind of messaging system (we usually use MQTT and already have it in place in multiple facilities).

 

Thus, could we simply add a Provider for MQTT and enable MQTT transport that way via the ditto-client or are there any considerations I am missing in my thoughts?

Or are there even plans to implement that already?

We have the luck that @Musti El-Sari just joined us to write his BA Thesis on this topic, so he could jump in a bit, I guess and it would be more sustainable than just concatenating jsons on our own.

 

What do you think?

Julian