anchor.diff:  `org.apache.camel.spi.Synchronization` API provides fine grained methods
   for `onCompletion` and `onFailure` for the two situations.
   
  +[source,java]
  +---------------------------------------------------------------------------
  +/**
  + * Our own callback that will gather all the responses.
  + * We extend the SynchronizationAdapter class as we then only need to override the onComplete method.
  + */
  +private static class MyCallback extends SynchronizationAdapter {
  +
  +  // below the String elements are added in the context of different threads so that we should make
  +  // sure that this's done in a thread-safe manner, that's no two threads should call the data.add()
  +  // method below concurrently, so why we use Vector here and not e.g. ArrayList
  +  private final List<String> data = new Vector<>();
  +
  +  @Override
  +  public void onComplete(Exchange exchange) {
  +    // this method is invoked when the exchange was a success and we can get the response
  +    String body = exchange.getOut().getBody(String.class);
  +    data.add(body);
  +
  +    // the latch is used for testing purposes
  +    LATCH.countDown();
  +  }
  +
  +  public List<String> getData() {
  +    return data;
  +  }
  +}
  +---------------------------------------------------------------------------
  +
   And then we have the client API where we call the <<http-component,HTTP>>
   service using `asyncCallback` 3 times with different input. As the
   invocation is Async the client will send 3 requests
   right after each other, so we have 3 concurrent exchanges in progress.
   The response is gathered by our callback so we do not have to care how
   to get the response.
  +
  +
  +[source,java]
  +---------------------------------------------------------------------------
  +MyCallback callback = new MyCallback();
  +
  +// Send 3 async request/reply message to the http endpoint
  +// where we let the callback handle gathering the responses
  +String url = "http://localhost:" + getPort() + "/myservice";
  +template.asyncCallbackRequestBody(url, "Claus", callback);
  +template.asyncCallbackRequestBody(url, "Hadrian", callback);
  +template.asyncCallbackRequestBody(url, "Willem", callback);
  +---------------------------------------------------------------------------
   
   [[Async-UsingtheAPIwiththeCamelclassicAPI]]
   Using the Async API with the Camel classic API
  
positive.code: 
  The route is the same, so its just how the client initiate and send the
  messages that differs:
  
  [[Async-UsingtheAPIwithcallbacks]]
  Using the Async API with callbacks
  
negative.code: return beforehand. And the messages that expect a reply, well yeah they
  have to wait anyway. So this can be accomplished like the route below:
  
  [source,java]
  ------------------------------------------------------------------------------------------------------------------------------
  // just a unit test but imagine using your own data format that does complex
  // and CPU heavy processing for decrypting the message
  DataFormat mySecureDataFormat = new StringDataFormat("iso-8859-1");
  
  // list on the JMS queue for new orders
  from("jms:queue:order")
    // do some sanity check validation
    .to("bean:validateOrder")
    .to("mock:validate")
    // use multi threading with a pool size of 20
    // turn the route async as some others do not expect a reply
    // and a few does then we can use the threads DSL as a turning point
    // if the JMS ReplyTo was set then we expect a reply, otherwise not
    // use a pool of 20 threads for the point forward
    .threads(20)
    // do some CPU heavy processing of the message (we simulate and delay just 500 ms)
    .unmarshal(mySecureDataFormat)
    .delay(500)
    .to("bean:handleOrder")
    .to("mock:order");
  ------------------------------------------------------------------------------------------------------------------------------
  
  WARNING: *Transactions and threads DSL*
  Mind that when using transactions its often required that the
  Exchange is processed entirely in the same thread,
  