anchor.diff:  better way to structure your code. For this, Vert.x provides _verticles_ - a simple agent-like model. Verticles are
   single-threaded classes interacting using asynchronous messages.
   
  -Open the `vertx-exercises/src/main/java/io/vertx/workshop/exercise/Exercise2.java`. In the `main` method, deploy the
  +Open the `vertx-exercises/src/main/java/io/vertx/workshop/exercise/Exercise2.java` file. In the `main` method, deploy the
   `Exercise2Verticle`. Then, implement the missing functionnality in the verticle class (`Exercise2Verticle.java`).
   
  -Run and check the result as in the previous exercise. Emit the request several time in a raw to check that your
  +Run and check the result as in the previous exercise. Emit the request several time in a row to check that your
   verticle is always executed by the same thread.
   
   [.assignment]
  
positive.code: 
  ### Exercise 5 - Request Reply and Composing actions
  
  Let's now mix the HTTP server and the event bus. A first verticle create the HTTP server, but to response to the
  request, it sends a message to another verticle and _waits_ for a reply. This reply is used as response to the HTTP
  request. This introduce the `request-reply` delivery mechanism of the event bus. This exercices is composed by a
  _main` class (`io.vertx.workshop.exercise.Exercise5`) and two verticles: `io.vertx.workshop.exercise
  .Exercise5HttpVerticle` and `io.vertx.workshop.exercise.Exercise5ProcessorVerticle`.
  
  
negative.code: ## Eclipse Vert.x
  
  We will attempt to explain Vert.x in just a few lines. Remember we said in the previous section that Vert.x is _"a toolkit for building
  reactive applications on the JVM"_.
  
  ### Vert.x in 10 minutes
  
  There are a three important points in this description: **toolkit**, **reactive** and **on the JVM**.
  
  Firstly, Vert.x is a **toolkit**. This means that Vert.x is neither an application server, a container, nor a framework.
  Vert.x is a plain old `jar` file, so a Vert.x application is an application that uses this `jar`
   file. Vert.x does not define a packaging model, all Vert.x _components_ are plain _boring_
   `jar` files. How does this impact you and your application? Let's imagine you are using a build tool such as
   Maven or Gradle. To make your application a Vert.x application just add the `vertx-core` dependency. Wanna use another
   Vert.x component, just add it as a dependency. It's simple, burden-less. Starting the application is a simple class
   with the `public static void main(String[] args)` entry point. There is no specific IDE or plugin to install to start using Vert.x.
  
  Therefore, to use the awesomeness provided by Vert.x, you just need to use it in your code. Be patient, how to do this will be
  covered later.
  
  Secondly, Vert.x is **reactive**. It is specifically made to build reactive
  applications, or more appropriately, **systems**. Reactive systems footnote:[Reactive systems and reactive programming are two
  different _things_. Reactive programming is a development model observing and manipulating data streams, while
  reactive systems are systems that react to requests, failures, load peaks and interact using async messages.] have
  been defined in the  http://reactivemanifesto.org[Reactive Manifesto]. While it's not a long document to read, we will further reduce it to these 4 bullet points:
  
  * Responsive: a reactive system needs to handle requests in a _reasonable_ time (I'll let you define _reasonable_).
  * Resilient: a reactive system must stay responsive in the face of _failures_ (crash, timeout, `500` errors...), so
  it must be _designed for failures_ and deal with them appropriately.
  * Elastic: a reactive system must stay responsive under various loads. As a consequence, it must scale up and down, and
  be able to handle the load with minimal resources.
  * Message driven: components from a reactive system interact using **asynchronous message-passing**.
  
  To help accomplish this, Vert.x is event-driven and non-blocking. Events are delivered in an
  _event loop_ that **must never be blocked**.
  
  image::event-loop.png[Vert.x Event Loop (simplified view),600]
  
  
  Let's explain why. Unlike traditional, let's say "enterprise", systems,
  Vert.x uses a very small number of threads. Some of these threads are _event loops_ which are responsible for
  dispatching the events in `Handlers`. If you block this thread, the events won't be delivered anymore.
  
  image::blocked-event-loop.png[Blocked Event Loop,600]
  
  This execution model impacts how you write your code, instead of the _traditional_ model of blocking code, your code is
  going to be asynchronous footnote:[Asynchronous: the caller does not wait for a returned response, but passes
   a _callback_ which is executed when the result has been computed] and non-blocking footnote:[Non-blocking: the code
    must not block the executing thread - so it must avoid blocking IO, long processing time etc.].
  
  