Book Review: "Real-time Web Application Development using Vert.x 2.0"

About Vert.x

I am following the evolution of the Vert.x project since its inception and I was expecting to see some books coming about the subject sooner or later. First of all, some explanation on what's Vert.x:

"Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications."

The product is 100% open source, licensed under the business friendly Apache Software License 2.0 and well documented. The project's founder and main maintainer is Tim Fox, of HornetQ fame.
Vert.x characteristics are nicely summarized in the related Wikipedia entry:

Vert.x is a polyglot event-driven application framework that runs on the Java Virtual Machine.

Similar environments written in other programming languages include Node.js for JavaScript, Twisted for Python, Perl Object Environment for Perl, libevent for C and EventMachine for Ruby.

Vert.x exposes the API currently in Java, JavaScript, Groovy, Ruby and Python.

Scala and Clojure support is on the roadmap.

The application framework includes these features:

• Polyglot. Application components can be written in Java, JavaScript, Groovy, Ruby or Python.
• Simple concurrency model. All code is single threaded, freeing from the hassle of multi-threaded programming.
• Simple, asynchronous programming model for writing truly scalable non-blocking applications.
• Distributed event bus that spans the client and server side. The event bus even penetrates into in-browser JavaScript allowing to create so-called real-time web applications.
• Module system and public module repository, to re-use and share components.

Few days ago I decided to purchase a recent book from Packt Publishing about the subject.

The Book

Title: Real-time Web Application Development using Vert.x 2.0

Language : English

Paperback : 122 pages

Release Date : September 2013

ISBN : 1782167951

ISBN 13 : 9781782167952

Author(s) : Tero Parviainen

I bought the eBook format only and I read it in both my iPad and computer screen, especially because the narration is mainly about building a fairly complete Web application, so I wanted to read and experiment at the same time, by entering the code by hand and running it step by step.

Below I provide a short summary of the book' sections and I will write some final comments about it.

Preface

The preface introduces clearly the content and objectives of the book

"Real-Time Web Application Development using Vert.x 2.0 will show you how to build a real-time web application with Vert.x. During the course of the book, you will go from the very first "Hello, World" to publishing a fully featured application on the Internet."

The scope is to build an editor with which people can create mind maps collaboratively. So, it is neither a too trivial application, nor something too complex. A good, balanced choice, with the additional bonus of learning a few of jQuery, D3 JavaScript library and MongoDB on the road.

What the book covers 

Chapter 1, Getting Started with Vert.x, guides you through the installation of the Vert.x 2.0 platform and its prerequisites. In this chapter, you'll also write your very first Vert.x application: the web equivalent of "Hello, World".

Chapter 2, Developing a Vert.x Web Application, covers the development of a full-fledged Vert.x web application, including both the server and browser components. You will become familiar with the architecture of a typical Vert.x application.

Chapter 3, Integrating with a Database, extends the web application from the previous chapter by adding support for persisting data in a MongoDB database, using one of the available open source Vert.x modules: the MongoDB Persistor.

Chapter 4, Real-time Communication, builds on everything you've learned so far
to deliver the secret sauce: real-time communication. You will develop a real-time, collaborative, browser-based mind map editor.

Chapter 5, Polyglot Development and Modules, presents some of the polyglot features of Vert.x, as well as the development of reusable and distributable modules,
by creating a Java module that is used to save mind maps as PNG images.

Chapter 6, Deploying and Scaling Vert.x, shows how to deploy your Vert.x application on Internet, by setting up a Linux server with continuous deployment. Finally, we discuss the basics of scaling Vert.x for growing amounts of users and data. 

My comments

One might argue that the official Vert.x documentation is already quite comprehensive and this book doesn't add much, but conversely I feel this book allows for a smoother approach to learning, without the need to browse and search too much around the Web site. Maybe somebody with already a working experience with Vert.x wouldn't gain a lot of new knowledge here, at the end I feel the book is more focused on Vert.x beginners, but anyway it contains a good amount of advanced tips to make it valuable for a wide audience.

Vert.x is a polyglot framework, so one can choose among a set of popular programming languages, with even more on the move, but the code in the book is mainly Javascript, also server side. On one hand this seems to restrict a bit the potential audience, as to fully understand the source code and the logic behind the mind map application a decent knowledge of Javascript is advisable, but on the other hand this could be very appealing to node.js developers, as they could immediately compare it with Vert.x. Then, also a client-side Javascript developer can easily follow the content and learn some server-side programming. I'm not sure on my side if I would pick Javascript for developing complex server-side logic, but adopting the same language for both client and server development undoubtedly has its own advantages, as the growing popularity of node.js testifies.

What I especially like in this book is the capacity to explain "full stack" concepts in small, easy steps. You learn about Vert.x and asynchronous message exchanges via the event bus, but also some client side programming techniques in Javascript. The bridge between client and server is built using the SockJS library, which provides real-time, full duplex, client-server communication through HTML5 WebSockets and other fallback mechanisms for older browsers.

Another plus of this book resides in its two last chapters, about modules and deployment. Chapter 5 provides a clear description of distributing and managing Vert.x applications through modules, while Chapter 6 goes into the fundamental topic of real deployment and scaling of Vert.x applications. As Vert.x applications are not distributed as standard Java EE packages, these final chapters are really a bonus and I wish to see more books that include at least some basic information about development, scaling and lifecycle management.

Conclusions

The book is very well written and readable. It is balanced, as it can support both the novice and the expert developer in exploring this excellent Web framework. I can definitely recommend buying it if you want to start studying in deep Vert.x.

Note: I actually bought this book by myself and not asked to review it by Packt or anybody else, so this article reflects my own independent opinion only.

References

• http://vertx.io/
• http://en.wikipedia.org/wiki/Vert.x
• http://www.packtpub.com/real-time-web-application-development-using-vert-x-2-0/book

XA Transactions

Reading MySQL documentation I have found a good description of how XA distributed transactions and two-phases commit work. I like to share it because it's short, clear and applies in general situations. It also teaches us why distributed transaction, being much more complex, should be managed very carefully to avoid severe performance penalties.

Applications that use global transactions involve one or more Resource Managers and a Transaction Manager:

A Resource Manager (RM) provides access to transactional resources. A database server is one kind of resource manager. It must be possible to either commit or roll back transactions managed by the RM.

A Transaction Manager (TM) coordinates the transactions that are part of a global transaction. It communicates with the RMs that handle each of these transactions. The individual transactions within a global transaction are “branches” of the global transaction. Global transactions and their branches are identified by a naming scheme described later.

The MySQL implementation of XA MySQL enables a MySQL server to act as a Resource Manager that handles XA transactions within a global transaction. A client program that connects to the MySQL server acts as the Transaction Manager.

To carry out a global transaction, it is necessary to know which components are involved, and bring each component to a point when it can be committed or rolled back. Depending on what each component reports about its ability to succeed, they must all commit or roll back as an atomic group. That is, either all components must commit, or all components musts roll back. To manage a global transaction, it is necessary to take into account that any component or the connecting network might fail.

The process for executing a global transaction uses two-phase commit (2PC). This takes place after the actions performed by the branches of the global transaction have been executed.

In the first phase, all branches are prepared. That is, they are told by the TM to get ready to commit. Typically, this means each RM that manages a branch records the actions for the branch in stable storage. The branches indicate whether they are able to do this, and these results are used for the second phase.

In the second phase, the TM tells the RMs whether to commit or roll back. If all branches indicated when they were prepared that they will be able to commit, all branches are told to commit. If any branch indicated when it was prepared that it will not be able to commit, all branches are told to roll back.

In some cases, a global transaction might use one-phase commit (1PC). For example, when a Transaction Manager finds that a global transaction consists of only one transactional resource (that is, a single branch), that resource can be told to prepare and commit at the same time.

The CAP Theorem

In this InfoQ video presentation Amazon's CTO Dr Werner Vogels discuss about availability and consistency for distributed systems. The central item is the "CAP theorem", Dr Vogels describes it starting by this question:

What goals might you want from a shared-data system?

- Strong Consistency: all clients see the same view, even in presence of updates
- High Availability: all clients can find some replica of the data, even in the presence of failures
- Partition-tolerance: the system properties hold even when the system is partitioned

The theorem states that you can always have only two of the three CAP properties at the same time. The first property, Consistency, has to do with ACID systems, usually implemented through the two-phase commit protocol (XA transactions).

In his presentation Dr Vogels explain why big shops like Amazon and Google, as they handle an incredibly huge number of transactions and data, always need some kind of system partitioning. Amazon then must provide high availability, for example a customer must always has access to the shopping cart, because it obviously means that the customer is committing to buy something. As for Amazon the third and second CAP properties (Availability and Partitioning) are fixed, they need to sacrifice Consistency. It means they prefer to compensate or reconcile inconsistencies instead of sacrificing high availability, because their primary need is to scale well to allow for a smooth user experience.

This IMHO leads to some easy conclusions: most legacy application servers and relational database systems are built with consistency as their primary target, while big shops really need high availability. That's why firms like Google or Amazon have developed their own applicative infrastructure. That's why, as Dr Vogels presentations explain well, a two-phase commit protocol is never an appropriate choice in case of big scalability needs. On this subject you can also read this article from Gregor Hohpe: Your Coffee Shop Does Not Use Two-Phase Commit

To scale-up what you really need are asynchronous, stateless services, together with a good reconciliation and compensation mechanism in case of errors. Second, your data model has a dramatic impact on performances, that's why Amazon has implemented a simple put/get API instead of running complex database queries, and why Google performances are due to the MapReduce algorithm: simplicity rules.