just as the title says, someone of you has had luck integrating Solace messages from an embedded application. I could only find their API to be used under an operating system, not for standalone applications.
Is there any stack or libraries to do the task from a 32bit microcontroller under C/C++?
You could always use MQTT from your embedded platform to connect to Solace.
Different endpoints can use different messaging protocols, so a telemetry reading going in via MQTT can be seamlessly fanned out over JMS and AMQP to different backends.
Solace PubSub+ Message Brokers natively support the OASIS MQTT 3.1.1 standard to meet the needs of connected devices and mobile applications. MQTT is a lightweight messaging protocol specifically designed for applications where a small code footprint is required, such as for embedded applications.
There are many free MQTT client libraries available for use. For example, an Arduino specific MQTT client is available here:
https://pubsubclient.knolleary.net/
Related
I was searching in the net about connection between STM32 microcontroller and AWS IoT core, didnt come across any. I cam across articles where the discovery board of STM32 is used to connect to AWS IoT core. But I want a simple way to connect the STM32 microcontroller to AWS IoT core with the help of WiFi module (since STM32 microcontroller boards dont usually have WiFi modules)
I tried searching as I have already told but didnt come any resources related to what I was searching. I was specifically looking for resources related to STM32F1 series.
You need internet connectivity to be able to connect to aws iot. That could be wireless or ethernet. STM32f4 could work with ethernet.
Or, you move to ESP32.
What I’ve done in the past is to connect a stm32L1 to esp8266 over spi.
AWS provides a tutorial on how to use the IoT Device SDK for Embedded C - https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.html
They also provide sample apps specifically ported for STM32 (STM32L4 discovery board - https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html) based on WiFi connectivity.
That can be a good starting point if you build it and review the codebase.
However if you want to use a different STM32 family then you will need to port the project to your specific hardware.
Also if you have a different WiFi module, you will need to rewrite the drivers to fit to your hardware configuration. (You can only use a WiFi module which supports TLS connectivity, as that is mandatory for the AWS IoT Broker connection).
Another approach: in the AWS console under IoT Core > Device Software > FreeRTOS Device Software (https://eu-west-1.console.aws.amazon.com/iot/home?region=eu-west-1#/software/freertos) there are preconfigured packs for download. Alternatively you can also customize a device pack for download. You will be able to find the same device (STM32L475 Disco board) listed there.
I'd like to use both Google's Native-client API and BlueZ for a senior design project but, I can't figure out if BlueZ is compatible the Native Client SDK. Does the full set of white-listed APIs include this library?
I'm uncertain if bluetooth APIs in general are white-listed for Android Native Client apps, but even if they are, there are not going to be native BlueZ APIs available on all devices or versions.
As indicated by Google (https://source.android.com/devices/bluetooth.html) as of JB 4.2 the native bluetooth stack is BlueDroid, which is based on Broadcom's stack. Before that time BlueZ was the default stack, but was replaced by some vendors with their own.
It may still be possible to install BlueZ on your newer OS device if it is rooted, but you cannot at all be certain the underlying stack on any random device will be BlueZ or BlueDroid, so if developing an app for distribution you would need to limit yourself to official APIs that Android provides (http://developer.android.com/guide/topics/connectivity/bluetooth.html), or maybe implement on each stack and detect at runtime what stack to use, assuming what you want to do is even possible with BlueDroid.
I'm looking for options that would allow a client to receive messages (push notifications) from a server. The client is an ARM/Linux embedded device similar in capabilities to a Raspberry Pi.
Because the client could be behind a firewall, I'd like to use message-oriented middleware (MOM) that can transport on top of HTTP. I think that rules out MOMs that are based on AMQP.
The MOM server should support the Linux platform. The MOM should also provide a C or C++ client library that can be compiled on an ARM/Linux platform.
I am aware of the HTTP long polling technique, as well as HTML 5 WebSockets and Server-Sent Events. But I'd prefer a higher-level (yet lightweight) solution that takes care of transporting messages between point A and point B over HTTP. It doesn't matter much if the messages have to be formatted as XML, JSON, plain text, or binary.
Two that I have used successfully are XML-RPC and gSOAP.
XML-RPC:
It's a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.
It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.
gSOAP:
The gSOAP toolkit is a C and C++ software development toolkit for SOAP/XML Web services and generic (non-SOAP) C/C++ XML data bindings. The toolkit analyzes WSDLs and XML schemas (separately or as a combined set) and maps the XML schema types and the SOAP messaging protocols to easy-to-use and efficient C and C++ code. It also supports exposing (legacy) C and C++ applications as SOAP/XML Web services by auto-generating XML serialization code and WSDL specifications. Or you can simply use it to automatically convert XML to/from C and C++ data. The toolkit supports options to generate pure ANSI C or C++ with or without STL.
According to my research, these are the available MOM technologies that use HTTP as a transport, and which feature a C/C++ client library:
XMPP
Extensible Messaging and Presence Protocol (XMPP) is a communications
protocol for message-oriented middleware based on XML (Extensible
Markup Language).The protocol was originally named Jabber, and
was developed by the Jabber open-source community in 1999 for near
real-time, instant messaging (IM), presence information, and contact
list maintenance. Designed to be extensible, the protocol has also
been used for publish-subscribe systems, signalling for VoIP, video,
file transfer, gaming, Internet of Things applications such as the
smart grid, and social networking services. (from Wikipedia)
ActiveMQ
Apache ActiveMQ is an open source message broker written in Java
together with a full Java Message Service (JMS) client. It provides
"Enterprise Features" which in this case means fostering the
communication from more than one client or server. Supported clients
include the obvious Java via JMS 1.1 as well as several other "cross
language" clients. The communication is managed with features such as
computer clustering and ability to use any database as a JMS
persistence provider besides virtual memory, cache, and journal
persistency. (from Wikipedia)
Zerogw
Zerogw is a http to zeromq gateway. Which means it listens HTTP,
parses request and sends it using zeromq socket (ZMQ_REQ). Then waits
for the reply and responds with data received from zeromq socket.
Starting with v0.3 zerogw also supports WebSockets. Websockets are
implemented by forwarding incoming messages using ZMQ_PUB socket, and
listening clommands from ZMQ_SUB socket. Each WebSocket client can be
subscribed to unlimited number of topics. Each zeromq message it
either control message (e.g. subscription) or message to a specified
topic which will be efficiently sent to every WebSocket subscribed to
that particular topic. (from the GitHub zerogw page)
There's also the HyperText InterORB Protocol (HTIOP), but TAO seems to be the only CORBA ORB that supports it. There doesn't seem to be anyone using it (please correct me if I'm wrong).
There is work in progress to make OMG's Data Distribution Service (DDS) web-enabled.
I'm also warming up to the idea of using WebSockets for bidirectional communications, despite their "low level" nature. For those interested, available C/C++ libraries include:
libwebsockets
websocket++
QWebSockets
Wt (C++ web development toolkit which includes support for WebSockets)
There is an open Websocket Application Messaging Protocol (WAMP) that provides asynchronous messaging patterns for remote procedure calls and the publish-subscribe pattern. There are a number of implementations for WAMP, but none of them are written in C/C++.
I am a novice in C++, but have a lot of experience in Java EE.
I need to write a small app which is heavily asynchronous. It receives data from HTTP and stores it in a Queue (it needs to have guaranteed delivery and very high throughput), something like ActiveMQ or OpenMQ, maybe via JMS.
Then another C++ app/listener takes out data from the Queue (through some Listener which is activated by the Queue directly, not by my pooling), connects to a MySQL database and does some business logic calculations and sends the message to another Queue.
In Java EE this would be a web app that would send messages to a JMS queue. Message-Driven Beans would be consumers of these messages in an EJB module, and a Session EJB would send messages to the outgoing JMS queue.
Can someone with C++ experience please explain some basics to me:
Is JMS the only option for C++ for guaranteed delivery Queues? Do you suggest ActiveMQ or something else, having in mind that the message Consumer would be in C++.
Do I need to create some kind of a multi-threaded daemon in C++ that listens for Queue messages, or is this thread creation (message consumption) part of ActiveMQ's implementation of C+ consumers?
Any other suggestions on how to implement the scenario above would be very much appreciated.
EDITED: I would prefer a message broker and client to be in C++. ActiveMQ is a Java product, which is not really what we need.
1 - JMS - Java Message Service - is just an API reference for Java and Java only. There is no standard in messaging that applies to C++ except for AMQP (which is, to my opinion, not really working cross implementation as good as it should). To C++ you kinda have to rely on specific vendor libraries for each message broker implementation.
Suggestions of implementations:
ActiveMQ - It has a nice C++ API (Called CMS) which is modeled and named after JMS - so you will feel familiar with the API. The main broker will run on Java non the less - might be the simplest choice.
IBM WebSphere MQ - Not open source, enterprise class broker that runs native (written in C), and has C++ libraries. Rather nice when you get over the learning curve and the price does not matter.
RabbitMQ - Very popular reliable messaging with high performance and open source. Has C++ client libs but is written in Erlang and runs within the erlang/otp runtime.
Apache QPID - Less known AMQP/JMS broker. Comes in two flavours server side, Java and C++ where the C++ broker has better performance. Comes with C++ client libs.
2 - For multi threading, the JMS specs does not really come with a solution either. It's more like the Java EE container (or Spring Framework) that simply wrapps the management of threads and relieves the developer from it. ActiveMQ does not come with much more than a few support classes in this case and as far as I know, none of the other vendor libraries does either. So, look for some library that wrapps threading (I have no clue) or deal with the consumer threads yourself. It shouldn't all that messy, done right.
We have to communicate with a C++ component from a Java EE web application and my proposal involved using JMS server to communicate with the C++ component which is located on other machine.
However the developer of the C++ component wants me to open up TCP/IP sockets from the webapplication and communicate over XML. My view is that socket programming in web application is error prone and will not scale well since there is a limited amount of sockets that can be opened up.
Please let me have your architecture/design preference on using JMS vs TCP/IP sockets.
Thank you
Of course it's case by case. But give HTTP a serious chance. It is a good way to cross platform boundaries. It gives you ways to swap out the backend easily and there are many ways to scale it. I've used it from various platforms to hit centralized authentication service written in modern language. I've also done the opposite by putting frontend to a legacy code by turning it into a web server.
The best part about HTTP is that it's a standard protocol, so almost any platform is able to serve it and consume it out of the box. HTTP(S) or TCP takes care of many of the issues like reliability and security.