Open source Java projects: Vert.x

Enterprise messaging and integration with Vert.x

1 2 3 Page 3
Page 3 of 3

The MyWorkerVerticle, which is shown in Listing 7, is designed to construct a response for the specified request path and send that response back to the Server2's Handler. The handler logs the response and then writes that response back to the HttpServerRequest that initiated the action. The only thing that is a little challenging is that before we're able to write back to the HttpServerRequest we need to specify the HTTP Content-Length of the response, which is just the length of the string we're returning.

Two additional Vert.x features are added to the Server2 class:

  • Logging: The container variable has a method named getLogger() that provides access to Vert.x's logger. This logger is very similar to log4j and provides methods like debug(), info(), and fatal() to log messages at different logging levels. By default, logging information will be echoed to standard output and will be written to a file named vertx.log located in the TMPDIR-defined directory.
  • Shared data: Sharing data between verticles is accomplished by executing the sharedData() method on the vertx instance and then invoking one of the shared data accessor methods. In Listing 4, we store data in a Map that is retrieved by invoking getMap(); you can likewise retrieve shared data in a Set by invoking getSet(). All of the verticles in your Vert.x instance have access to the same shared data using the same paradigm, so it is a way for you to share immutable data between verticles.

Listing 7 shows the source code for the MyWorkerVerticle class.

Listing 7. MyWorkerVerticle.java

package com.geekcap.vertxexamples;

import org.vertx.java.core.Handler;
import org.vertx.java.core.eventbus.EventBus;
import org.vertx.java.core.eventbus.Message;
import org.vertx.java.core.logging.Logger;
import org.vertx.java.platform.Verticle;

import java.util.concurrent.ConcurrentMap;

public class MyWorkerVerticle extends Verticle {
    @Override
    public void start() {
        // Register a listener
        EventBus eb = vertx.eventBus();
        Handler<Message> workerHandler = new Handler<Message>() {
            @Override
            public void handle(Message message) {
                Logger logger = container.logger();
                logger.info( "MyWorkerVerticle just received a request for: " + message.body() );

                // Examine our shared map
                ConcurrentMap<String, String> map = vertx.sharedData().getMap("mymap");
                logger.info( "Shared data: " + map.get( "mykey" ) );

                message.reply( "<html><head><title>Worker Response</title></head><body>Hello, from the worker verticle</body></html>" );
            }
        };
        eb.registerHandler( "request.worker", workerHandler );

    }
}

The MyWorkerVerticle class creates a new Handler instance with a handle() method that processes messages from the Server2 class. Recall from Listing 6 that one of the arguments passed to the send() method was a Handler instance that could be invoked by the message recipient. Listing 7 invokes message.reply(), which sends a response back to the originator (which in this example is the Server2's Handler.)

The MyWorkerVerticle class obtains access to the EventBus and then registers its handler to listen to messages sent to the "request.worker" destination, to complete the loop.

As far as functionality, the MyWorkerVerticle simply constructs an HTML document and returns it back to the Server2 class. You could build upon this example by connecting to a database or reading data from another server to retrieve the data with which to build the response.

And you'll notice that MyWorkerVerticle retrieves the shared data from the vertx's sharedData() map.

In conclusion

As enterprise systems evolve in complexity, integration has become one of the biggest programming challenges for software developers. Vert.x addresses the complexity of integration in a couple of ways: First, it is built around an event bus that loosely couples verticles while supporting multiple programming languages. Regardless of whether code is written in Java, Ruby, Python, or JavaScript, you can seamlessly integrate it inside the Vert.x event bus. Additionally, the event bus natively supports asynchronous messaging and an event-driven architecture, which yields high-scalability and loose-coupling.

This article has presented an overview of Vert.x, its unique vernacular, and the core components that it combines to build highly scalable enterprise solutions. I demonstrated both a web server and a messaging system written in Vert.x, using the latter example to develop a publish/subscribe messaging and a point-to-point messaging solution. In the latter example I also demonstrated event logging, shared data, and the difference between standard and worker verticles. While this article has been introductory, I've touched on some of the major features that illustrate the power of Vert.x, a solution similar to Node.js but built on the JVM. I hope that you are inspired to learn more about Vert.x and the types of programming challenge it resolves.

Steven Haines is a technical architect at Kit Digital, currently working onsite at Disney in Orlando. He is the founder of www.geekcap.com, an online education website, and has written hundreds of Java-related articles as well as three books: Java 2 From Scratch, Java 2 Primer Plus, and Pro Java EE Performance Management and Optimization. He lives with his wife and two children in Apopka, Florida.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3