Availability and performance are two words that often characterize the requirements found behind most commercial software. As the volume of processed information continues to grow together with the rise of social networks and added complexity of online services, web servers are now increasingly confronted with heavy loads and higher numbers of concurrent requests. In this chapter, we will explore different ways to deal with better performance and scalability by covering the following topics:
- The Async library, a new way to simplify asynchronous code, including examples of web services composition
- Akka, a toolkit and runtime that simplifies the building of concurrent, distributed, and fault-tolerant applications based on the actor paradigm
Concurrency and asynchrony are the techniques that most programming languages use to enhance response time and scalability, and Java is no exception. Asynchronous method calls is a technique by which the caller of a potentially time-consuming computation does not wait for a response, but rather continues to proceed with other code while the computation is ongoing. The caller will be notified once running has completed, receiving notification of either a successful result or a failure message.
The traditional way to deal with asynchronous code in Java has mostly been through the registration of callbacks, that is, placeholders that are called upon completion. Complexity tends to increase when working with asynchronous code as the sequence of execution is not deterministic, that is, the order of execution is not guaranteed. Executing code concurrently is, therefore, more difficult to test since it may not produce the same result on successive invocations. Furthermore, as callbacks are not composable (which means that they can't be chained and combined in a flexible way), it can be cumbersome to mix several asynchronous computations together to achieve more advanced scenarios, resulting in the well-known problem of callback hell when such projects increase in size (cases where the complexity is at such a high level that it is difficult to maintain and guarantee the proper execution of a piece of code).
Concurrency is also encountered when code is executed on multiple cores. Recent hardware architectures are now embedding several cores into the same machine as a way to continue achieving better performance when the minimal physical size of transistors has been reached.
Another consequence of dealing with concurrent code is that multiple threads of execution can get into conflicts when trying to access the same resources. Mutable state in a program, which is not protected against shared access, has a higher risk of being incorrect. Making sure that the concurrent code executes correctly often comes at the cost of increased complexity. Java thread synchronization mechanisms, for example, using locks, have led to solutions that are difficult to understand and maintain.
The functional approach of Scala striving for immutability is a first step towards easier concurrency. Scala Improvement Process (SIP), which can be seen as the equivalent to the Java JSR process in Scala, has proposed an SIP concerning SIP-14-Futures and Promises. These notions are not new as they have already been used in many other languages when writing concurrent code, but the new proposal tries to merge the various Scala implementations of Futures.
Note
Futures and Promises are objects through which you can later retrieve the result of some asynchronous execution after it finishes. To learn more, visit http://en.wikipedia.org/wiki/Futures_and_promises.
As stated in SIP-14-Futures and Promises:
Futures provide a nice way to reason about performing many operations in parallel—in an efficient and non-blocking way.
From this proposal, an implementation has been created, which is now the basis of many Scala libraries that deal with concurrent and asynchronous code.