Tim Fox is the creator of Vert.x and a very good speaker (did I mention this in my previous post, yes I think I did).
Vert.x is a relatively low level framework to give you a strong basis without opinion (in the sense that it is not limiting your options). Extensibility is therefore also one of the aspired characteristics. Vert.x was inspired by Erlang and Node.js. Rather than just being a copy of node.js on the server side, it has been build up from scratch to include the desired characteristics. Some characteristics from node.js Tim wanted to divert from:
- Programming language: Node.js can only be used when coding with JavaScript. Vert.x is mainly server side and therefore uses the strength of the JVM to support multiple languages.
- Single threadedness: Node.js has inherently a single thread. In contrast to node.js, vert.x is a server side framework and therefore the full capacity of the server(s) can be used. Maximizing CPU utility is one of the key goal.
Next to the Vert.x thread model, it is also kind of rebelling towards the traditional application servers in the sense that simplicity is a key goal. See the image below for all the key goals.
Vert.x is inherently asynchronous. The building blocks in Vert.x are verticles. A verticle runs within a single thread (it is guaranteed that the same thread will be used). A verticle can only communicate with other verticles throught the eventbus. JSON is the standard for communicating structured data between verticles, but you can define your own data format if you want. The event bus is the nervous system of Vert.x and one of its strengths. However, you can use this event bus in other ways, like connecting to it directly from the client, even in a clustered environment. While being the strength, the event bus currently also has some weaknesses:
- Currently the assumption is that you are running on a trusted network. No security is in place to make sure the data on the eventbus is confidential.
- When developing in Vert.x, you should know that all data passed to the event bus should be immutable (when serializing). Otherwise, a copy will be made and you will not be looking at the same object.
- You might think that putting messages on the event bus is similar to messaging with a queue like ActiveMQ or RabbitMQ. Though it has similarities, sending messages over the event bus is transient, meaning that there is no transport guarantee.
Verticles can be run directly (without packaging first) from command line or can be packaged in an executable JAR file. All it needs is a JDK to run.
Another great feature is in the area of clustering. A high availability fail over mechanism can be used (facilitated by Hazelcast). When a node goes down, the verticle will automatically be deployed to another node.
Vert.x 3.0 is currently being developed and we’ve already discussed some key features. It is Java 8 only. When moving to version 3 you have to move to Java 8. Instead of the Rhino JavaScript engine in Vert.x 2, the Nashorn JavaScript engine will be used. Vert.x 3 also comes with a way to generate Rx-ified versions of your API, runtime metrics (exposed in JMX and available in event bus) and distributed data grid functionality. A snapshot version of vert.x 3.0 is currently available in maven central that you could try out.
