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++.
Related
I have a nodeJS server which receives user POST/Streaming requests from a web-UI.
I have a C++ back-end engine process which does some calculations and sends API calls to other 3rd party services. The API call requires certain info provided by the web users.
My question is what is the best solution to pass the request data received on NodeJS and send over to the C++ process?
WebUI -> NodeJS ->???->> C++ engine
Make your C++ application listen on a TCP or Unix socket.
Make your NodeJs application connect to that socket and exchange messages. For messages you can use Google Protocol Buffers, JSON, etc..
If the information what you have is still at JavaScript layer, then you have to implement C/C++ Addons implementation. If you already have some type of native module, then you may follow the same design based on that (very likely existing module could be based on NAN). If you are plan to introduce a brand new native module then it is a good time to consider N-API. You can get more information about it from.
https://nodejs.org/dist/latest-v11.x/docs/api/n-api.html
https://github.com/nodejs/node-addon-api
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/
According to the wikipedia page, SOAP is a protocol specification.
What does it mean? Aren't all protocols specifications?
In this answer, the author says that SOAP
is a protocol (or at least tries to be)
Tries to be? In the sense that it's not agreed upon?
SOAP is a protocol as per specs. As wiki as well its protocol.
As per wiki-
SOAP (originally Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to induce extensibility, neutrality and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
As per english dictionary Protocol-
specialized computing a computer language allowing computers that are connected to each other to communicate
As per Network terminology protocol-
In information technology, a protocol is the special set of rules that end points in a telecommunication connection use when they communicate. Protocols specify interactions between the communicating entities. It could exist at various levels, e.g. There are protocols for the data interchange at the hardware device level and protocols for data interchange at the application program level.
If you try to refer all three above explanations, SOAP falls into Application level communication protocol.
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.