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:

The reasoning behind each is simple:
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. 

The other side of the fence works in a similar fashion in that objects only respond to the methods they have, but also I tend to map exchanges and queues to groups of related objects.  The exact topology depends upon the requirements (do something in parallel on a fanout exchange or dispatch to workers from a shared queue, etc) but the fundamental concept is a method call is just a message send, and objects communicate by sending messages.   The JSON encoded s-expression just makes translating these message sends to multiple languages trivial with well behaved off the shelf libraries available for everything but the dynamic method call. I've now implemented this pattern in C, C++, Java, Forth, Erlang, JavaScript, Lisp, Python, Ruby, Perl, Smalltalk, Self, and Ocaml.  Languages which natively support dynamic dispatch are much easier, but most any language that can fork on a test can support this. (ie most programming languages which are not DSLs)

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:
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.