Websockets JSON Symbolic Expressions and Message Passing Architectures

This spring, I will be releasing a new open source platform written in C, with bindings for many popular programming languages, which will make building message passing applications dirt simple. The cornerstone of this approach is translating all abstractions into a standard symbolic expression:

"Subject", "verb", ... Predicate ...

Where the subject is the object receiving the message, verb is the method handling the message, and the predicate is the list of arguments passed to the method. Using JSON to store symbolic expressions make it easy to translate to JavaScript in the browser, but also is easy to translate into most popular languages without much hassle. The dynamic dispatch in an Object Oriented fashion allows the consumer of a message stream to define a public interface as a sequence of operation attached to the handling of a message as if it were just another method invocation. This means one does not need to create IDL layers and other constructs that confuse the translation.

Right out of the box, the platform will support Lua, JavaScript, Perl, Python, Ruby, Erlang, Objective-C, C++, and Java. C will also be supported using a special form of structured data, which the libraries use internally. Additionally, support for invoking stored procedures in PostgreSQL will be provided transparently, so that applications can speak directly to the database without an intermediate layer. This radically changes the nature of connectivity, as your application can treat the database as yet another object to which you can send messages.

Also out of the box, an AMQP interface layer will provide support for routing messages via topic and fan out exchanges. These forms will be represented by three classes of objects:

The nature of the pathways created by these objects will abstract the implementation details of message routing from the end user, and provide a programmatic interface for real time route management. This form of software defined routing allows us to remove the limitations of the underlying transport mechanism from the viewpoint of the applications developer.

But coolest of all becomes the opportunity for creating "corporate objects" where the logical interface for an object is implemented on the other end by a swarm of specialized objects which all respond to the same message. For example, say you want to update a Person record:

"Person", "update", "Dave", { "salary": 1000000, "currency": "USD" }

For this message, we might have 3 or more objects handling the Person.update message:
Rather than having just one application handle this message, a suite of applications handle the processing. When a new requirement arises due to needing to report the change to state and federal agencies for tax purposes, we simply add new objects to the mix:
Having the ability to do multiobject dispatch of a single message dramatically reduce the complexity of designs, and increase the responsiveness of the application at scale. Additionally, adding redundancy and performance largely becomes a problem of adding hardware and designing idem potent operations on shared state.

Coming soon... A web of objects...