The edge use-case with substantial hardware is quite different from the classic IoT use-case. Also, the fact that you want to use messaging between clients on the edge device is also a significant difference. Therefore, my answer certainly would change given that the underlying assumptions from my previous answer are invalid.
I have no doubt that some of our users are running a broker on their edge devices. The broker can be tuned to run effectively even on very modest hardware when necessary. I can't rightly say whether that's a "good usage" in your use-case when it's clear that important details are easy to omit. Also, it's hard to say whether core bridges [1], federation, or even broker connections [2] would best fit your needs. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/core-bridges.html [1] https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html On Tue, Mar 14, 2023 at 3:12 PM Yoann Gini <yoann.g...@gmail.com> wrote: > Thanks for your input Justin! > > Maybe IoT was missleading here, if I speak about EdgeComputing does it > change your answer? > > One of the reasons I was looking for that architecture and that I forgot > to mention was the ability to use also the MQ between multiple services > locally to the edge. > > So each edge would be autonomous for their own internal messaging and then > have federations for upstream communications. > > I was in my context forgetting that IoT usually mean low end device. > > In my context it’s IoT but with 64 GB of RAM, i7 CPU and Cuda capabilities > on the GPU. > > So maybe Edge Computer is more appropriate wording. > > Yoann > > > Le 14 mars 2023 à 20:02, Justin Bertram <jbert...@apache.org> a écrit : > > > > Generally speaking, the software that runs on IoT devices is designed > with > > the unique constraints of IoT in mind (e.g. poor or intermittent network > > connectivity, limited processing capacity, small amount of memory, low > > power, etc.). > > > > MQTT, for example, is often used for messaging in IoT contexts and it is > > designed to be light-weight and has features like will messages, retained > > messages, link stealing, session expiration, etc. to facilitate unique > IoT > > use-cases. > > > > Furthermore, MQTT client implementations offer additional features not > > outlined in the MQTT specification. For example, most Paho MQTT clients > [1] > > offer the ability to automatically reconnect, buffer messages when > offline > > (which will be sent automatically when the connection is re-established), > > and persist messages (in case the application crashes before it has a > > chance to send them). > > > > In my opinion, adding a broker to an IoT device is not a good idea. It's > > adding complexity where it isn't really required. It will make > > configuration, deployment, and debugging more difficult, and it will > > require more hardware (which is notoriously limited in IoT). A good MQTT > > client implementation should be able to provide you with all the features > > you need to operate effectively in an IoT context. > > > > > > Justin > > > > [1] https://www.eclipse.org/paho/index.php?page=downloads.php > > > >> On Tue, Mar 14, 2023 at 8:52 AM Yoann Gini <yoann.g...@gmail.com> > wrote: > >> > >> Hello, > >> > >> I'm new here and I'm working on an IoT issue where I'm wondering if > >> Artemis and federated queue could help. I'm learning the software in the > >> same time I'm trying to achieve something, so I would like to have your > >> opinion on this: will it work? Is it a good idea? And do you have sample > >> config / blog post to recommend to learn to achieve that? > >> > >> The idea: IoT devices with some computing capability running local > needed > >> services as well as an Artemis local instance, with upstream set a Cloud > >> located one. > >> > >> Configuration in bidirectional to allow both Cloud to pass commands to > IoT > >> and IoT to report feedback to Cloud. > >> > >> Goal of Artemis here in the IoT as federated layer (and not directly IoT > >> service connected to the cloud one) would be to provide some sort of > >> caching capabilities which would allow the local service to not have to > >> handle disconnected state. Local service will still be able to publish > to > >> local Artemis and read what was lastly make available before a > connectivity > >> cut. And when the Internet recovers, the federation (if I understand it > >> well) should resume bidirectional transfer of feedback and orders. > >> > >> Does that make sense for you? Is it a good usage of the solution that > has > >> some chance to reliably works? > >> > >> If so do you have any recommendations for the implementation or any blog > >> post / conference I should look at to learn this? > >> > >> Cheers > >> Yoann > >> > >> > >
