Programming the Internet of Things
In certain circles there is a lot of excitement about messaging protocols like AMQP and MQTT. If you like B2B messaging like writing FX software for financial institutions, or just like building swarms of robots that coordinate via packet radio, there's something there for you.
One of the key bits of both AMQP and MQTT is that they are payload agnostic. You can shovel JSON data, or bitmaps, or memory dumps, and the protocol just doesn't care. This is great for building applications, but it leaves a gap for middleware to help broker the interactions which drive communication.
My take on this has been two approach:
- ship Forth code over the MQ and drive behavior (MQTT)
- ship s-exp in JSON and eval on the receiver (AMQP)
The reasoning behind each is simple:
- on my embedded boards I run Forth and C&C is done with Forth
- on my web based apps, the AMQP exchange communicates between web apps that all parse JSON, and I can always map object, method, args... to a backend object or module method invocation.
There are advantages to each scheme. In the case of Forth, the vocabulary of the dictionary defines which words from the message are acknowledged. Unlike most Forth systems, if a word is undefined or not a number, mine simply ignores it. This allows for messages to get sent to the wrong place, and as long as the domain of each component does not overlap with the domain of another routing errors are avoidable.
Where this scheme works really well is when you have a single wireless signal that you are broadcasting across many receivers, some of which you want to act in concert. By evaluating only the words you know from the stream you can send a single stream of instructions to control and coordinate multiple physical systems through what amounts to selective hearing. I call this a Grandpa Protocol, but it may have a technical name in literature that I have yet to find.
Having a methodology for communicating between objects is more important than the transport mechanism that gets the message there. Having a methodology that is essentially "ship LISP code!" is absolutely the simplest thing that you can do that will work. The theoretical underpinnings are solid, the invocation semantics are clear and well defined, and you aren't tied to any particular implementation of the underlying object system.
So in summary:
- Objects are implemented in any language and attached to a messaging transport layer
- The program is the communications between Objects which are the messages in flight
- These messages are simply symbolic expressions which each object interprets in its own idiosyncratic way
And that's it. A simple methodology that works with any payload agnostic messaging protocol that allows a network of things to cooperate and effectively communicate.