Services allow an application's logic to be exposed without worrying about its underlying language or platform, with access done by either processing a WSDL contract in order to form a SOAP request, or by simply calling a REST access point. In either case, there is no trace of the language or platform used to back a service -- or for that matter what language you use to access it. However, under certain circumstances the language you use in either client or server can facilitate a service's design. The circumstance I will talk about next is concurrency, and how the language Erlang is designed to deal with such behavior.
Concurrency is a classical problem in computer science. In fact, its one of the earliest concepts presented in Programming 101 as the 'dining philosophers' problem. In very simply terms, concurrency issues arise when two logical sequences or processes are executed at the same time and can clash with each other.
These situations are common in areas like graphical interface programming, where a lack of attention to concurrency can lead to behaviors like mouse pointer 'locking' or 'sputtering' -- since mouse movement and application logic are executed at the same time, this can lead to potential clashes that cause the cited behavior. Another area is applications targeting multiple processor machines, or the more recent multi-core processors which replicate the same multi-processor behavior. In order to take advantage of such resources, applications need to be designed with concurrency in mind.
So what does all this have to do with service architectures? It turns out that both a service's client and server can be prone to concurrency problems. This can occur if either a slew of requests comes into a backing service or a client makes calls that require concurrency protection. Most programming languages can deal with concurrency, but not in the simpler way Erlang does. To illustrate this, I will talk about concurrency techniques used in a more widely known language like Java.
In Java, concurrency is the land of multi-threaded programming. Its here that Java constructs like synchronized blocks and methods, as well as, explicitly starting and stopping threads is used to allow concurrent behavior. Multiple threads can run their course in the same program (process) without one having to wait for the other. However, care must still be taken that each thread does not access certain resources concurrently, which is the whole purpose of the aforementioned Java constructs.
This makes multi-threaded programming an often difficult task, because if not done properly, it can lead to many of the side-effects associated with concurrency, like: Race conditions, deadlocks, and 'starvation'. So why is Erlang different ? For starters, Erlang doesn't use the concept of threads, but rather uses processes as its main building block -- which being coarser grained units, guarantee resources are protected and if shared don't require special constructs or syntax.
Still, you may be thinking 'Java and many other languages can also spawn processes, what is the difference?' The difference is that Erlang processes can communicate by asynchronous message with each other. This is in stark contrast to most languages, in which processes are self-contained and incommunicated. In Erlang not only can processes exchange messages with each other, but since communication is performed asynchronously, the risk of a concurrent side-effect like a deadlock or 'starvation' is minimized, since no mutual exclusion or locks are performed.
Though Erlang itself is not new -- having emerged in the 1980's inside Ericsson -- it has enjoyed a renaissance with the popularity of multi-core processors and the heavier demands being put on distributed applications now that software as service has gone mainstream. Besides Erlang the language, Erlang is distributed as Erlang/OTP(Open Telecom Platform), where OTP represents a large collection of utilities and libraries used by the language.
Additionally, Erlang has also carved out an important niche for itself in distributed applications. Among the most interesting Erlang projects you will find : YAWS a web server that in certain tests -- Apache vs. YAWS -- has been demonstrated to have superior performance to the stalwart Apache web server, Apache CouchDB a network database server, ErlyWeb a web framework, as well as, Facebook's integrated chat system which hovers around 70 million users.
As can be attested by the designers of these last projects, the architecture solved by each of these projects would either be extremely difficult to solve or not possible at all, were it not for Erlang's capability to support long-running, concurrent, highly reliable distributed systems. In fact, such is Erlang's feature of processes communicating by exchanging messages, that this same technique is one of the primary advantages to using Java's JVM-compatible language Scala, support which is provided by the Scala Actors library.
If trends are a strong indicator, the ascendance of multi-core processors and distributed applications based on SOA principles are all but assured in the coming years, hence, now more than ever is an excellent time for you to revisit the way you address concurrency issues in applications, by using either Erlang or some if its copycat like initiative like Scala Actors.
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and web-based software, he blogs regularly on these and other software areas at http://www.webforefront.com/
