In software development there is a constantly changing environment: programming languages are regularly released with improved API’s and more powerful frameworks, standards are updated to support innovations in hardware, cheap computation and storage means it is now widely available on all kinds of devices, and connectivity has become inherently supported. It is this that catalyses the evolution of how apps are written. One important part of this evolution is related to computational concurrency i.e. the ability for logic to be executed at the same time. Hardware has supported this for a long time and it is what has allowed applications to become multi-threaded where each thread within a process can execute logic concurrently.
As hardware and programming languages have improved, the support for writing multi-threaded apps has also become more widely available. The real driving force behind this is the insatiable appetite for fast applications with rich functionality that can run, not only on computers but also on an ever increasing range of devices. These kind of apps are more than just multi-threaded though, they usually depend on multiple processes working together in a coordinated fashion.
Take a website as an example, it is hosted on a server which has it’s own process with multiple threads and it is viewed on a web browser that also has it’s own process with multiple threads. In order to deliver a functional website the two processes have to be coordinated, this is done with the glue between them: HTTP. The glue is sophisticated, it does more than enable process coordination, it is layered on top of TCP so there is also a remote aspect at play where the processes are running on separate hosts.
A website and browser have very clear and importantly distinct responsibilities: one serves data and the other renders and interprets the data. But what happens when you have coordinated processes that can run remotely, which also have similar responsibilities? This allows you to capitalise on multiple threads to achieve performance while at the same time scaling across multiple processes and hosts. This is what is needed to really scale up in an industrial way and the result is a technology that makes clustering, cloud type redundancy, efficient use of big data and grid computing a reality. These are what I have come to think of as real-time multi-process apps.
When it comes to coding, there is big difference between writing an app that runs in a single thread and one that uses multiple threads. The complexity of multiple threads interacting with each other, forces a disciplined approach underpinned by an appropriate threading model. In short, it is hard to develop a multi-threaded app and if you don’t get it right, it is hard to identify and fix defects. The complexity and therefore difficulty increases by orders of magnitude with real-time multi-process apps, these require a carefully designed framework that shields you form the complexities of managing threads and processes so that you can focus on implementing business logic.
This is what we strived to do when we wrote ClearConnect, our real-time multi-process application framework. It manages interactions of multi-threaded processes generically which is complex and difficult, so we stuck to core concepts to help us rationalise this difficulty. For example we standardised data flowing between processes, we made components work with no complex configuration (convention over configuration + discoverability) and we made everything ClearConnect does transparent (comprehensive logs + tooling). A more complete description of our concepts can be found in the Concepts and Programming Manual. The result is a framework with a complete yet clear API that works with nothing except a Java enabled computer.
Bearing in mind the complex nature of multiple threads and processes, ClearConnect is relatively easy to understand and it can be supported with some basic knowledge. We have tested and compared it so we know it is fast at runtime, and we have used it to develop business applications so we know it is quick and easy to use.
In my next post I will go into some detail of how real-time multi-process apps work, based on my experiences in industry and with ClearConnect.