The synchronous vs. asynchronous communication debate is like deja-vu all over again

Since computing began there has been a non-battle between asynchronous and synchronous communication. Why a non-battle?  Because with application development the norm is to concentrate on the synchronous (tightly-coupled) even though the asynchronous (or decoupled) is both more flexible and generally applicable. At Impact 2013 in Las Vegas, a new manifestation of this so-called “wrong” choice appeared, this time associated with mobile apps and devices. Yogi Berra would have been proud that his deja-vu insight continues to apply.

By far and away the most common way of implementing communications today is the hypertext transfer protocol  (HTTP). Fundamentally this is a request/response protocol that must wait for a response once a request has been issued. On today’s highly reliable wired networks using synchronous processing makes reasonable sense, even if it often delivers inefficient use of a network’s resources.

In the mobile world, wildly fluctuating quality of connection services is common: One minute a connection will be solid, while just round the corner there is minimal signal. Using HTTP in this environment doesn’t help, especially when there is a very real cost per byte for the data that HTTP or other synchronous protocols use.

Far more preferable would be a loosely coupled connection, one where the two sides of a communication do not need to wait for each other. Conceptually it would be so much more efficient if you can use loosely coupled communications so that there is only the minimum usage of your data plan.

Software technologies that do this have been around for years (think IBM’s MQSeries or TIBCO’s Rendezvous, MSMQ or JMS). But in a mobile world of mostly iOS and Android, three different considerations have prevented or inhibited adoption of asynchronous processing in modern mobile devices:

  1. The existing messaging solutions mentioned above are all heavyweight (to differing degrees) and, because they need multi-tasking to function as designed, they are not really implemented in mobile devices.
  2. The numbers of mobile devices need support are orders of magnitude more in quantity that these traditional IT messaging solutions can realistically support.
  3. Most developers of mobile solutions prefer synchronous communications because this is what they know. However, in doing so they risk behaving like their “normal” application developer predecessors in mainstream IT.

At Impact 2013, one particular announcement indicated a change: IBM’s new MessageSight is a single appliance that can handle 1 million simultaneous connections and process multiple millions of messages a second. Combine this with the availability of message queuing telemetry transport (MQTT) clients that can run on mobile devices and whole new possibilities open. These clients are freely available as part of the open-source M2M project Eclipse Paho and can work with open-source brokers like Mosquitto, as well as IBM’s own ones. This further emphasizes that technologies for reliable, asynchronous communications that are also suited to a mobile world are now available.

It does not, however, mean that mobile app developers will adopt the most appropriate model for mobile communications. It would be nice to believe the right solution will win, especially given the cost of today’s mobile data and the wastage consumed by synchronous mobile communications. But don’t hold your breath. History has shown that synchronous is the default, even when asynchronous should be chosen. The danger is that yet again we will not learn from history.