Introduction

How do you translate traditional API’s into REST? Many applications face this problem. We may already have an implementation that exposes a typical functional API. In the previous post, I discussed some of the essential properties of a REST API. In this post, I’ll take a simple functional API and convert it to REST resources.

A Simple Address Book

Let’s use a simple example of an address book. Although the example is simple, it is interesting enough to spur discussions that we’ll cover in more details later.

The above diagram is in UML. The interface may manifest itself as a set of Ajax calls or perhaps a simple API in some programming language. E.g. as an interface in Java:

interface AddressBookService {

  public void addContact(Contact c);

  public Collection<Contact> getAllContacts();

  public Contact findById(String contactId);

  public Collection<Contact> findByName(String name);

  public Collection<Contact> findByAreaCode(String areaCode);

  public void removeContact(String contactId);

  public void updateContact(String contactId, Contact contact);

  public Call callContact(Contact c);

  public Call dialNumber(String digits);

}

We also need some data structures to carry the information (often called DTO’s). If we stick to Java as our language', we would have to build some JavaBeans that defines the Contact and perhaps also the Call.

The Challenge

We want to convert the address book into a set of REST resources. The question is now, what are the resources? 

You can think of the REST API as an adapter that converts the user’s conceptual model to that of the implantation. Our language for describing the user’s conceptual model is the definition of resources. Our challenge is to find the most logical resources from a user’s perspective.

The Obvious Resource

The “contact” seems like an obvious resource. The address book has a set of contacts. Can we define all the functionality of the address book service into simple REST calls around a “contact” resource? 

If we decide to create a resource around contacts (or more correctly, a resource-set contacts with resource instances such as “John Doe, 512-555-8989”), what functionality do we cover?

Let’s explore this with a simple table where map REST methods on the contact resource to the original API. Notice that I’ve used ‘..,’ in the URL. The ‘…’ is worth a new blogpost by itself. At PayPal the ‘…’ would be ‘https://api.paypal.com/v1/addressbook'. I’ll just use ‘…’ to indicate ‘some base URL that precedes the resource name’.

As you can see, most of the methods in this interface had straightforward mappings into REST. However, we’re still left with a few methods (and consequently also features) that have not been mapped and do not have an obvious mapping.

How About the Calls?

The two methods that we did not map are:

• callContact
• dialNumber

These methods do not have an obvious resource. Or more correctly, they may map to obvious resources in an experienced REST designer’s mind, but it is very likely that if we had several REST experts there would be at least 2 different opinions of the obvious design.

Here is a set of strategies that you may see:

• Controller interface
• Conceptually this would perhaps be seen as a method sent to a contract
• Assuming I wanted to make a call to one of my contacts with the id 1234, the REST call may look like this:
• URL: …/contacts/1234/call
• Verb: POST
• Body: Empty
• Separate resource for call
• For this design, we are asking the clients to create a new resource-instance every time they call
• We could call the resource “calls”
• To make a call to a contact, we would a POST to the “calls” resource. E.g.:
• URL: …/calls
• Verb: POST
• Body: { “contactId”: 1234 }

In our example, I would argue that the approach of separate resources is superior (although I know that that may be controversial). The hint to why I think so is that we also have a method for calling an arbitrary number that can now be easily mapped. I also think this approach is more extendible to possible new requirements such as:

• All calls to a previous contact
• URL: …/calls
• Verb: GET
• Query parameters: ?contactId=1234
• All calls to an area code:
• URL: …/calls
• Verb: GET
• Query parameters: ?areaCode=512

The ultimate judge on which is a better API is your clients. The question you have to ask is what is the most logical/easy to use model for them!

Other Interesting Discussions

With the introduction of the “calls” resource, we have mapped all the original features of the original API. There are some other questions that we could have explored that may have led to a different design.

1. Can a client have more than one address book?
1. If YES
1. Can a contact be shared across multiple address books?
1. If NO
1. Would it be better to design the contacts as sub-resources of the address book?
   E.g.: …/address-books/12345/contacts/1 
2. Is a call in the context of an address book
3. Can address books be shared? 
2. Can we do more than call a contact? E.g., send SMS, email, etc.?
1. If YES
1. Are the SMS/email/etc. somewhat similar to a call (in other words, should we perhaps have a more abstract resource called “reach-out” that encompasses calls, emails, SMSL etc.)

In a later blog post, I’ll discuss how to explore these questions by building domain models. However, for this post I’ll keep it simple. The design we have suggests the following:

• The client has exactly one address book
• We’re interested in calls as separate resources

It is important to note that the answers to the questions may have led to very different designs. Also, since REST API’s are often exposed to the public, it is important to think about future extensions before you release an API, hence, the questions above should be explored with the future in mind.

Did We Improve the World for Our Clients?

All we have done is to map the existing API into new calls. We could easily have exposed the functional API as a set of Ajax calls. However, I would argue that we have gained a few very important advantages by converting the interface to a REST style:

• We now have a shared model with our clients. 
• We have introduced a consistency into the design. A consistency in abstraction level and a consistency in how the API works.
• With proper REST resource design, we also have a clear and predictable path for future extensions of the API.

Documenting the API

A great side effect of the consistency of REST API’s is that clever open-source developers have provided a set of tools that makes it easy to expose API’s. Although it is outside the scope of this post to discuss these tools, I’ll explore these tools and discuss how they work.

The first tool that I’ll discuss is Swagger. Swagger is a tool that allows you to create a JSON based specification of your resources and the methods you expose. The specification can be used by Swagger tools to generate a web-interface that acts as the documentation portal for your API. The API portal also allows your clients to test out your API without having to write any code.

Another tool worth mentioning is RAML. RAML works in a very similar way to Swagger. It arguably has a nicer authoring environment.

Perhaps in a later blog post I’ll highlight some other options for how to define REST API’s. At SciSpike, we have developed some tools that we are about to release to open source that I believe provide an even nicer authoring environment.

Guidelines for Converting Functional API’s to REST

Our example is a little too simple to justify all the guidelines below. I will come back in later blog post to justify the list:

1. Functional interfaces can NOT be automatically converted to REST. Expect a complete redesign when moving from traditional API’s to REST.
2. Always reflect your clients view. The name and the number of resources you create should be largely driven by what your client wants to see.
3. Interfaces should be durable. Changing an interface may be a big deal and may be very costly.
4. Interfaces should be extensible. Evaluate what are likely changes to the interface over time. Can you expand the features without having to change the existing API?
5. Interfaces should be well documented. In the REST world, you have no excuses for not providing good API documentation (e.g., with Swagger or RAML).
6. Build a domain model. Expect some part of your interface to be easy to translate (those are typically directly related to CRUD(F)) whereof other parts require significant efforts to find the correct resources. The missing resources cannot be found without a domain modeling effort (I’ll explore this in my next post).
7. Avoid controllers. Often controller API’s are introduced where another ‘event-based’ resource would be more extendible.

Conclusion

In this blog post, I’ve discussed how to convert traditional functional API’s into REST API’s. In a traditional API, there are usually some obvious resource candidates and the methods on the API can easily be mapped to the CRUDF options for the resources. However, some of the features of your API may be more difficult to map to REST. In later blog posts, we’ll explore some of the most difficult resources. One of the great advantages to REST is that in converting your API the implementors and the clients of the API share a common model at a consistent level of abstraction and with predictable ‘method calls’.

Introduction

This is the first blog in a series of blogs on REST. In these blogs I’ll try to demystify the REST. I’ll discuss what REST is and some suggestions for how you can design good REST APIs.

First, let me acknowledge some of the sources of these posts. I’ve been teaching REST API’s for one of my favorite clients PayPal over the last year. In the process I’ve had the fortune of working with the PayPal services team. The discussions with these individuals and my students have led to a great number of insights on my side. In particular, I’d like to acknowledge Jason Harmon with whom I’ve collaborated on creating the courses that we currently teach at PayPal. Jason’s insight into REST and passion for good API’s are legendary.

The current plan is to provide a set of blog posts. As I build them, I’ll inject direct links into the below list:

• What is REST? (covered in this first delivery)
• Domain driven development of REST APIs
• Versioning of REST resources
• An extensive example of how I build REST API’s
• PATCH vs. PUT
• Controllers vs. event-soucing

Is REST services a new idea?

I actually once started an article on why REST is not new. However, halfway through the article, I had to stop and admit to myself that there are some quite new ideas in REST. I’ve seen similar ideas to REST in various books through the time. For example some of the ideas in Cheesman&Daniels book on “UML and Components” had many of the same design ideas as what was later contributed to REST.

This is not to discredit Roy Fielding. Fielding suggested the ideas that we now call REST in his PhD theses and I think his ideas are brilliant.

The main new ideas of REST in my opinion are:

• Services are organized around resources
• Resources have unique URL
• Resources can be manipulated through HTTP
• The encoding of the resources can be determined by the client
• The introduction of Hypertext (or more correct Hypermedia) to the API

All of these new ideas lead to some really interesting benefits. Probably the most important one is a great consistency in the way the API appear to the clients.

What is REST?

REST is short for REpresentional State Transfer. Of course, that doesn’t really convey it all, so let me give you my elevator pitch:

REST is an architectural strategy for defining API’s where the clients and service providers share a common information model and the client activation of the services takes the form of requests for lookup, updates or creation of information in the shared information model. The information model takes the form of sets of resources and their relationship. 

The protocol of communication between the client and the service provider is HTTP where the resources are identified by a URI, the intent of the query or update of the information model is expressed through HTTP verbs and the format of the information exchange is defined by the content type. The desired content types(s) can be controlled by the client if the service provider supports more than one type.

What is a resource?

Central to the idea of REST is the concept of a resource. To help you understand what resources are, I would want to separate two different words to make the narrative a little clearer and also to allow me to draw parallels to those with an object-oriented background.

• Resource-Set
• A resource-set is a collection of resource instances. When communicating with a service provider a client would address the resource set to perform operations such as
• Create a new resource instance
• Find a resource instance
• For those of you with an object-oriented background, imagine the resource-set as a class
• For those of you that have a relational database background, imagine the resource-set as a table
•  Resource-Instance
• A resource-instance represents an individual conceptual object that a client and the server agree upon
• Our operations on resource-instances are typically
• Read its state (or information)
• Update its state (or information)
• Remove it from our conceptual resource-set
• For those of you with an object-oriented background, a good analogy would be an instance/object
• For those of you with a relational database background, think of the resource-instance as a record

The analogies that I suggested for relational databases or object-oriented technologists may be helpful in the beginning, but you have to eventually make the leap to understand that the resource (set or individuals) are conceptual not physical.

Let’s illustrate with an examples from various domains:

• Hospital domain
• “Patients" is an example of a resource-set
• An resource-instance is “Joe Doe, a patient admitted to the hospital”
• “Admissions" is an example of a resource-set
• “Joe Doe’s admission to the hospital on 2/3-2015 11:01PM CST” is an example of a resource-instance belonging to this set
• Rental car domain
• "Rental car agreements” is an example of a resource-set
• “Sarah Smith’s rental at Hertz At San Francisco Airport on 2/3-2013 9:01 AM PST” is an example of a resource-instance belonging to this set

The point that the resources are based on a conceptual model is very important. The fact that we have a resource-set called Patients, does not necessary mean we have a table called patient in our implementation. All we are saying is that as a service provider (e.g., a hospital-admittence server), we understand what you mean by Patient and we have an API that allows clients to manipulate patients. We may for example provide a resource-set upon the URI http://api.hospitals.com/patients which allows you to lookup all our know patients instances (or resource-instances).

Whether a client is referring to a resource-set or a resource-instance is clear in every service invocation by the URI that they use. A service provider will publish one URI that refers to the resource-set. A resource-instance is always addressed by adding a unique identifier to the resource set. Let me give you a real-world example. At PayPal we have a resource-set that can be addressed at:

https://api.paypal.com/v1/wallet/payments

If I wanted to create new payments or find payments, I would use this URI. However if I wanted to read an resource-instance, in this case a specific payment, I would address that at:

https://api.paypal.com/v1/wallet/payments/293759715

Notice that the URI of the resource-instance is identified by the resouce-set + “/“ + the identifier of the payment.

The CRUDF idea of REST

REST suggest that most of the things we do as clients of services is to manipulate these conceptual resource-instances. In particular, we may Create, Read, Update, Delete and Find instances. Notice the F is not normally used. This may very well be my own invention. As I was writing this, I looked to see if someone else had used the same term. I did find SCRUD (S for search), BREAD (Browse, Read, Edit, Add Delete), so not an original though from my side. I’ll just continue using CRUD(F) as I’ve been using this term when teaching and I believe many of the readers of my blog are ex-students :)

Another idea in REST is that we’ll identify what we want to do by a combination of URI and HTTP verbs. That is, we can clearly see if the intention of any client request by simply knowing the URI and which HTTP verb. HTTP supports a set of verbs. Not all of them are used in REST. Most of us are familiar with the difference between GET and POST (GET is typically used to open a page in your browser, POST is often used to submit a form from your browser). In addition to the GET and POST, we also use PUT, PATCH and DELETE.

In theory, that gives us 10 combinations (two dimensions; instance vs set and the 5 verbs). In practice, we only use 6 combinations though.

Let me show you in a simple table.

Notice that leaves a set of combinations. Although these combinations are perfectly valid and the semantics of such operations can be defined, they are rarely used. Just for completeness though, let me give you the combinations and explain why they are seldom used:

• DELETE on a resource-set.
  The semantic of this would be to delete all resource-instances in the resource-set. We don’t usually expose this for two reasons.
1. The operation is “too dangerous”
2. It is difficult to handle partial failure. What if we managed to delete a subset of the resource-instances? Of course we can define the behavior and allow this combination, but it is usually not used in API’s I’ve studied
• PUT on a resource-set.
  The semantic would be to replace reachable resource-instances in resource-set with the new list that we are “PUTting”. The reasons for this not typically supported is the same as for the DELETE on the resource-set
• POST on a resource-instance.
  I’m not sure what the semantics of such an operation would be, but I know from teaching that students have suggested using this when the client gets to specify the resource identifier. I think this is a bad idea. If you want to support client-derfined resource identifiers, the identifier should be part of the payload (more about that later).

A simple example

Let’s design a simple ToDo application. Let’s say we want to create a service that allows clients to produce a list of things to do. The todo-items describe what client wants to do and when the task is due.

The first thing to do is to try to define the resources. In this example the resource-model is very simple. In later blogposts I’ll show how to use domain models to find the resources. The only resource here is the list of todo items. The REST API may looks something like this

• To CREATE a new todo item
• URI = resource-set
• E.g.
• http://api.sample.com/todos 
• HTTP verb = POST
• The data of the new todo item will be passed to the service in the body of the request
• To READ a specific todo item
• URI = resource-instance
• E.g.:
• http://api.sample.com/todos/123
• 123 is the resource-instance identifier
• HTTP verb = GET
• The data of the requested todo item will be passed in the body of the respose
• To UPDATE a specific todo item
• URI = resource-instance
• HTTP verb = PUT
• The updated todo item will be passed to the service in the body of the request
• To DELETE a specific todo item
• URI = resource-instance
• HTTP verb = DELETE
• To FIND a set of todo items
• URI = resource-instance
• HTTP verb = GET
• The set of resources will be returned to the client in the response body

Implementation of RESTful Service

There are some great technologies available that makes the creation of a RESTful service quite trivial. Here are some technologies that you may want to explore broken down by the programming language/platform they work on:

• Java
• There are a number of libraries available. I would recommend the use of JAX-RS based services such as:
• RestEASY
• Apache CXF
• Jersey
• Apache Wink
• .NET/C#
• WCF
• ASP.NET
• Python
• Django REST Framework
• eve
• Flask
• Scala
• Spray
• You can also use the JAX-RS providers since Scala integrates with Java
• Ruby
• Grape
• Rails-API
• By convention
• PHP
• By convension
• Phalcon
• Recess
• Node.js
• Express and convention
• Restify
• Loopback 

Conclusion

In this article, I’ve highlighted some some of the basic principles of REST. In the next article, I’ll take a simple example of a functional API and design some REST resources.

References

• Roy T. Fielding, Principled design of the modern Web architecture
• Wikipedia’s Article on REST
• The PayPal API 
• API Evangelist Blog
• Jason Harmon, How to design API’s that last

Introduction

Over the last 10 years I’ve seen a change in the way the top engineers/architects design, architect and deploy software. This new generation of computer scientists have their eyes firmly focused on quality attributes such as availability, scalability and fail-over-capabilities; issues that are rarely discussed in most enterprises.

Many companies tell me they have moved to web-scale and deploy to the cloud, however, when I study their architecture in detail I notice that they do not architect the software in a way that allows for scale. For some of them, my warnings come too late when their success catches up to them and their systems are not able to cope with the increased traffic.

In this article, I’ll explain why the way we traditionally architect software systems doesn’t scale and suggest some approaches for how to improve the scaling of your software.

Moore’s Law

Gordon E. Moore, the cofounder of Intel Corporation, observed that the number of transistors in a dense IC doubles approximately every 2 years (later adjusted to 18 months). As software developers we were made to look like heroes by the improvements in hardware. The software we built ran twice as fast a couple of years later.

The software speedup trend no longer holds for most large-scale software systems. Only those that write software in a way that allows you to take advantage of the hardware improvements continue the trend of Moore law. This excellent illustration (not sure exactly what the original source is, it is flagged as sharable in Google Images, so I’m simply linking to one of the places were it exists), show us why we no longer can rely fully on the improvement of hardware.

Notice how we keep adding more transistors (fulfilling Moore’s law). The computers are continuing the trend of becoming more and more powerful. However, the method of improvement has changed. Clock speed is no longer the main source of the improved performance (that trend stopped around 2004). Today, we improve performance by adding more cores. 

In addition to the increasing number of cores on individual machines, we also are trending towards computing on a set of machines (mainframes are not quite dead yet, but even those are often constructed using a grid of computing units).

Here is the bad news for us software developers:

Unless you change the way you write code, you will not be able to take advantage of the hardware improvements. 

I think Herb Sutter put it best

 “The Free Lunch is Over!!!” - Herb Sutter (Dr. Dobb’s Journal, 2005)

Herb Sutter goes on to say:

"Concurrency is the next major revolution in how we write software"

Amdahl’s law

To understand why Mr. Sutter predicted, “the Free Lunch is over”, we have to take a look at what has been named Amdahl’s law (sometimes also called Amdahl’s argument, named after Gene Amdahl and a presentation from 1967!). Amdahl’s law states that the maximum performance increase achievable by adding more CPU’s at a problem is inverse propositional to the percentage of the code that runs sequential.

The graph above (source Wikipedia) shows a rather trivial relationship. If the percentage of your code that has to be run sequential is 5% (0.05), then the maximum speedup of your system when adding more processors is 1/0.05 = 20X. If 25% of your software is sequential, your max performance by adding cores is 4X. 

The Amdahl problem in traditional enterprise architecture

Most traditional enterprise architecture runs primarily sequential algorithms. In fact, I would argue that over the last 20+ years we have deliberately been constructing languages, platforms and frameworks that promote sequential programming. 

The main reason for us to promote sequential programming has been that it is (arguably) significantly easier on the programmers. We optimized for quality attributes such as readability, maintainability, ease of programming, etc.

In a sequential code, it is very easy to understand the state of the program/algorithm. We know that the list of statements is executed one-after-the-other. If the program counter is on statement 4, we know that statement 3 has been completed and that statement 5 will be executed next (after 4 is complete). 

We also constructed various ways of locking resources so that the programmer was guaranteed exclusive access and did not have to worry about interference from other programs. This locking was typically achieved with locking semaphores or using transactions (e.g., SQL transactions). 

The ease of programming, we though, led to fewer bugs, easier to maintain code, etc. We were taught not to optimize if it made the code harder to read. The argument was often:

“If it doesn’t run fast enough, we can always throw more hardware at it"

Amdahl’s law shows that this approach simply doesn’t work. At some point (quite an early point with current algorithms), you’ll run into the max potential scale. Perhaps this was not an issue for you. If you are building software that services less than 100 concurrent users, you probably never had to worry about this. However, if you intend for your software to be used by thousands (or perhaps millions) of concurrent users, you eventually have to change the way you construct your software.

In some of our projects, we have to support several million concurrent users/transactions. If we built software the traditional way, we would simply not be able to keep up, no matter how much hardware you put on the problem.

Good for us, there are known ways to construct software that promote parallelism and hence increases our chances to scale. We’ll take a look at a couple of interesting approaches later in this article, but before I discuss some of these approaches, perhaps we should first focus on what kind of synchronization/sequential algorithms we try to avoid.

Resource synchronization

Most enterprise software takes advantage of lightweight threads to ensure some degree of parallelism. This allows a programmer to start several sequential programs at the same time. Unfortunately, these programs rarely achieve orthogonality. In particular, they often share resources. The good news is that we already have invented ways for the multiple programs to collaborate when accessing the resources.

Unfortunately, the most common collaboration is to sequentialize the access to the resource. That is, if more than one parallel task need to read/update the same resource, we ‘queue up’ the tasks and only allow one of the programs to read/update the resource at one point in time. While one task is accessing the resource, the other tasks are suspended waiting for the accessing task to complete.

Sequential to improve readability

Let’s take a look at a typical algorithm in enterprise software:

1
2

log(“we are about to open the database”);
connection = db.getConnection();

A compiler will ensure that the two statements above are executed in sequence, however, they could really have been executed in parallel. Most likely, there is no need for the program to wait for the log statement to be complete before opening the database. 

If one studies a typical sequential algorithm, there are often lots of opportunities for parallelism. However, the style/rules of how the program is constructed often prevents natural parallelism. 

Concurrency and parallelism

I’ve read different books giving completely different description of concurrency and parallelism. Books that focus on low level execution tend to specify the difference as:

Concurrency is when two threads of execution can make independent progress (but does not necessarily execute at the same time). Parallelism is when the two threads of execution make progress at the same time. 

If you read a book on design or  architecture, you may have read:

Concurrency is when two program incidentally work separately but may have interference when accessing resources. Parallelism occurs when two programs were designed to work at the same time with no interference.

I’m going to focus on parallelism in the design/architecture form. That is, I’ll focus on deliberately designed programs that can run independently.

Actor model

One famous computation model that promotes parallelism is the actor model. The actor model is a mathematical model for concurrent computation, but the ideas have been actualized in several programming environments. Perhaps one of the most famous such environments have been concurrency model of the Erlang programming language. 

The actor model is inherently concurrent. From Wikipedia:

An actor is a computational entity that, in response to a message it receives, can concurrently:

- send a finite number of messages to other actors

- create a finite number of new actors

- designate the behavior to be used for the next message it receives.

There is no assumed sequence to the above actions and they could be carried out in parallel.

Perhaps in a later blog article, I’ll go through the actor model in details, however, the linked wiki article is quite good and I’ll refer to it for further details. 

There have been many critics of the actor model. The most typical complaint about the actor model is that it is difficult (some say impossible) to compose actors. I actually strongly disagree with this statement, I think the composition is different than what people are used to. I believe when designing with actors, one naturally designs clusters of actors that collaborate on some task and that a careful architect/designer will compose the actors into what I call conversations. However, that is a discussion for another article.

Another criticism (which I do agree with), is that the programming model is more difficult and that only a subset of the programmers out there will master this paradigm. In particular, programmers seem to have problems proving the correctness of their program when some required behavior requires collaboration between a set of actors

Lambda architecture

A quickly emerging architectural pattern is called “Lambda Architecture”. Personally, I find the name quite misleading, but trying to be compliant to the rest of the world, I’ll use the term in this article (The Lambda comes from the idea of using Lambda Calculus, Lambda being a letter in the Greek alphabet that Church used to represent a functional abstraction… A long derivation and in my opinion a suboptimal name). 

In a Lambda Architecture, the processing of incoming data is delayed as long as possible. This is achieved by storing non-mutable facts and processing these facts at a later time. The facts are often simple time-series data. Some of the facts have to be processed in real-time, but in most application, a surprisingly small subset of the facts requires real-time attention. 

Let me try to illustrate with an example:

Say we are building a banking system for online trading (e.g., PayPal, Google Wallet). We’re bringing together payers and payees. It is important to us to ensure that we know what the account balances are in real time. However, the individual transactions and all details around them (e.g., where was it performed, what did they buy, what browser did they use, ...) can be processed at our convenience (or at least several seconds/minutes/hours or perhaps even days later).

Using the Lambda Architecture, we would separate out the real-time data (the account balances) into a data store with extreme performance (e.g., some distributed memory model) from all other data. When a transaction is performed, the balance is checked and updated based on some real-time data store.

The non-real-time data would be stored as facts in a specialized distributed database.  We typically store is the incoming event with a time-stamp and all the available knowledge of the event. It may be as simple as a log file, but it could be more sophisticated using a specialized time-series database (our (SciSpike’s) default architecture uses Cassandra which has proven to be perfect for this purpose). Since the facts are stored and never updated, this storage doesn’t require typical locking and we only strive for eventual consistency (as opposed to real-time consistency).

At some later time, we then compute specialized views from the sequence of facts. The views work on the dataset in total atomicity, we can parallelize the generation of these views with ease (e.g., using separate map-reduce tasks).

Popular programming environment

Today we have several frameworks that promotes parallelism. I’ll focus on a couple of them and discuss why they make it easy achieve parallelism. 

Non-blocking and asynchronous programming environments

One popular new(-ish) technology is Node.js. Why is it that Node.js has become popular so quickly? There are many reasons:

• The popularity of JavaScript
• The ease of getting started
• The anti-framework initiatives

Although the above properties of Node.js may be the most commonly sited, I’m going to focus on one aspect that is related to the topic at hand, namely how Node.js promotes parallelism.

For most of you, you may be terrified to hear that Node.js uses a single thread! It’s like we went back to the old Windows environment where there was a single event dispatcher thread that processed all incoming events. I’m sure some of you can remember the hourglass and total lack of responsiveness when someone decided to do something that took time on the event dispatcher’s thread. So how can this improve parallelism?

Node.js achieves its parallelism by using non-blocking libraries. What we mean by that is that whenever we execute one of the functions in the library by using non-blocking asynchronous communication (Node.js runs on the Google V8 engine that implements a complete set of non-blocking functions) .

So, for example, say we want to read some data from a console. In node this would be done this way:

1

console.read( function(err, data) { /* process the incoming data*/ } );

The code here is quite different from most other environment where the supplied I/O functions would suspend the calling thread until the input was collected from the user. In Node.js, we ‘sending a message’ to the console asking it to read some input, then we’re passing on a function that will handle the next steps when the data has been collected. It may very well be that the Google V8 engine uses a separate thread to read the user input from the console, however, as a developer I’ve delegated this problem to the V8 engine.

When programmers use the asynchronous messaging style, the algorithm often is naturally concurrent.

Other languages have introduced similar concepts.

• Java
•  Introduced non-blocking I/O from version 1.4. 
• JEE 6 had partial support for non-blocking I/O and JEE 7 will have full support. 
• The new concurrency library provides many features for supporting algorithmic parallelism (e.g., futures)
• Libraries are coming starting to take advantage (e.g., AsyncLogger in Log4J), Vert.x
• Scala
• Very strong support for parallelism
• Akka framework (also available for Java programmers)
• C#/.NET
• Async and await
• RX extension
• Python
• Twisted

Conclusion

References

• Gordon E. Moore: "Cramming more components onto integrated circuits”, Electronics, Volume 38, Number 8, April 19, 1965
• Gene M. Amdahl: “Validity of the single approach to achieving large scale computing capabilities”, AFIPS spring joint computer conference, 1967
• Herb Sutter: “The free lunch is over, a fundamental turn towards concurrency in software”, Dr. Dobb’s Journal, 30(3), March 2005
• Eyerman & Eeckhout: "Modeling Critical Sections in Amdahl’s Lawand its Implications for Multicore Design”
• Carl Hewitt: “A universal modular ACTOR formalism for artificial intelligence”, IJCAI, 1973.
• Nathan März: “Big Data”, Est. publication date Nov 2014, early draft available for download
• Hausenblas, "Applying the Big Data Lambda Architecture", Dr. Dobbs, Nov 2013

Electronics, Volume 38, Number 8, April 19, 1965