We use Apache ActiveMQ as the message-oriented middleware (MoM) layer between some of our platform services. As opposed to a centrally orchestrated process involving web services, such a MoM retains the central relay point for messages while leaving the decision logic on joining, parting and message filtering to the clients. Distributed architectures can benefit from such properties. Unfortunately, ActiveMQ is rather big: it weighs in about 30 MB in its standard distribution. After some trial and error, our package metadata was optimised to bring it down to less than 5 MB for pure Stomp/OpenWire protocol handling. While this is still too much from a functionality vs. effort point of view, it makes the component manageable and usable for a live system. After all, most of the work during the last days was invested into our upcoming demonstration at the Future Internet Symposium in Berlin.

Several interesting alternatives seem to exist which might be worth an analysis regarding their capabilities, performance and memory footprint. In particular, the RabbitMQ Stomp Gateway and the stomp.erl client are two potential competitors implemented in Erlang, while ØMQ is written in C++.

From our research perspective, the programming language is the least interesting factor, though. A more interesting question is whether the messaging layers, protocols and communication endpoints can be made more discoverable than they are at the moment. In fact, this problem extends to databases and other integration schemes as well, which is of practical importance as we've experienced with our packaging efforts of modular, standalone platform services linked into an integrated platform. A possible solution would be to create an ontology for the capabilities of platform services and resources and make use of it at system initialisation time. This way, instead of manually configuring each service to make use of the MoM, a dynamic reconfiguration depending on the system load and other factors would automatically select the appropriate messaging layer. Apparently, today's systems still lack a uniform access to all of their available resources and capabilities. This prevents an easy solution to this problem to appear in a predictable time.