Java Reference
In-Depth Information
State data for WebSockets should be stored in the user properties map on the session,
accessed via
Session.getUserProperties()
. Only serializable objects should be
stored in this map. Application state data shouldn't be stored in member variables, static
variables, or on the local file system. In a load-balanced environment, the application con-
tainer may roll over servicing of an endpoint to another node. Only data stored in the ses-
sion would thus be available on the new node. While the application may work correctly in
development on a single node, the behavior could change once the application is deployed
to multiple nodes with a load balancer.
WebSocket endpoints should use EJBs for accessing transactional resources such as data-
bases. Avoid injecting data sources into a WebSocket and accessing the database directly.
First, you don't want WebSocket endpoints holding onto resources, such as a database con-
nection, the entire time the WebSocket is in existence. Second, WebSockets shouldn't con-
tain application logic. Logic should be implemented in either POJOs, if it doesn't touch
transaction-based resources, or in EJBs.
WebSockets provide infrastructure for implementing your own communication protocol.
WebSocket connections can be opened not only in web clients using JavaScript but also
from iOS and Android applications. Supporting iOS and Android applications is different
from supporting a web client. Because the JavaScript code is always downloaded from the
server by the web browser, a web client usually has the most recent code. But in the case
of native clients, the clients could be a couple of versions behind. Consequently, the sub-
protocol feature should be used from the outset for versioning. Unless the application is
feature-complete with the first release, there will undoubtedly be revisions to the commu-
nication layer that won't be backward--compatible.
Currently, JSON is the favored format for data exchange, especially when dealing with mo-
bile devices. Although JSON isn't self-documenting and lacks many of the more advanced
features of XML, including validation with XML Schema, it's lightweight and suitable for
situations where there are bandwidth and processing constraints. XML is verbose and re-
quires a significant amount of overhead to process. On mobile devices this overhead affects
battery life and application responsiveness.
WebSocket connections from the client should be used sparingly. The administrator ex-
ample for ActionBazaar opened two WebSocket connections to the server. The use of two
connections was done to demonstrate two different approaches to implementing endpoints,
