In this post, let’s explore the less talked about Web Socket Client API and how to leverage it within a Java EE 7 container itself

Web Socket Server API rules

The server side API of JSR 356 (Web Socket API for Java) is most commonly used for building Web Socket endpoint implementations. More often than not, from a client perspective, the standard JavaScript Web Socket API is leveraged by the HTML5 (browser) based clients which attach themselves to web socket server end points and enjoy bi-directional and full-duplex communication. You would have seen common examples such applications such as live maps, stock tickers, games, screen sharing etc – all these use cases are perfect for Web Sockets and Java EE 7 is the ideal platform for building scalable Web Socket driven back end.

What about the Web Socket client side API ?

The Web Socket specification includes a client side API as well and its mandatory for all JSR 356 (e.g. Tyrus, Undertow etc) implementations to provide one. There are quite a few use cases wherein a browser based / end user facing web socket client might not be required.

Example

Consider a scenario where you want to connect to a third party Web Socket end point, consume it’s information and persist it for later use ? Maybe for further analysis ? In such cases, its useful to leverage the client API within the Java EE container itself.

Let’s explore this with a simple example.

(annotated) Web Socket Client

Note: the logic for @OnMessage was excluded on purpose and has been implemented in a different way (clarified later)

package blog.abhirockzz.wordpress.com;

import javax.websocket.ClientEndpoint;
import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.Session;

@ClientEndpoint
public class StockTickerClient {

    @OnClose
    public void closed(Session session) {
        System.out.println("Session " + session + " closed");

    }

    @OnError
    public void error(Throwable error) {
        System.out.println("Error: " + error.getMessage());

    }

}

A Stock Ticker (info) JPA entity

package blog.abhirockzz.wordpress.com;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "STOCK_TICK")
public class StockTick implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String name;
    private String price;

    public StockTick(String name, String price) {
        this.name = name;
        this.price = price;
    }

    public StockTick() {
        //for JPA
    }

    //getters and setters omitted ...
}

A Stateless bean

• Handles persistence of Stock Ticker info
• Executes its operations against the default JDBC data source provided by the Java EE 7 container (convention over configuration in action!)

package blog.abhirockzz.wordpress.com;

import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class StockInfoPersistenceService {

    @PersistenceContext
    EntityManager em;

    public void save(String name, String price){
        em.persist(new StockTick(name, price));
    }
}

Singleton EJB

• Leverages the Web Socket ContainerProvider API
• Initiates the connection to a web socket server
• Injects the StockInfoPersistenceService bean and uses it within the addMessageHandler implementation

As per previous note, the (persistence) logic which could have been embedded in a @OnMessage annotated method within the StockTickerClient class has been included here. This is because the injection of the StockInfoPersistenceService (stateless) bean was failing and the instance itself was being resolved to null.

package blog.abhirockzz.wordpress.com;

import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;
import javax.websocket.ContainerProvider;
import javax.websocket.DeploymentException;
import javax.websocket.MessageHandler;
import javax.websocket.Session;
import javax.websocket.WebSocketContainer;

@Singleton
@Startup
public class StockServiceBootstrapBean {

    private final String WS_SERVER_URL = "ws://api.stocks/ticker"; //fictitious
    private Session session = null;

    @Inject
    StockInfoPersistenceService tickRepo;

    @PostConstruct
    public void bootstrap() {
        WebSocketContainer webSocketContainer = null;
        try {
            webSocketContainer = ContainerProvider.getWebSocketContainer();
            session = webSocketContainer.connectToServer(StockTickerClient.class, new URI(WS_SERVER_URL));

            System.out.println("Connected to WS endpoint " + WS_SERVER_URL);
            session.addMessageHandler(new MessageHandler.Whole<String>() {

                @Override
                public void onMessage(String msg) {
                    tickRepo.save(msg.split(":")[0], msg.split(":")[1]);
                }
            });
        } catch (DeploymentException | IOException | URISyntaxException ex) {
            Logger.getLogger(StockServiceBootstrapBean.class.getName()).log(Level.SEVERE, null, ex);
        }
    }

    @PreDestroy
    public void destroy() {
        close();
    }

    private void close() {
        try {
            session.close();
            System.out.println("CLOSED Connection to WS endpoint " + WS_SERVER_URL);
        } catch (IOException ex) {
            Logger.getLogger(StockServiceBootstrapBean.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

That’s pretty much it. Although this was a relatively simple example, its not too hard to imagine that one can apply any sort of complex business logic on the information received by the web socket server endpoint. You might also want to think about sending messages to connected clients in an asynchronous fashion using the session.getAsyncRemote#sendAsync method