Java Reference
In-Depth Information
tpRequests
for either multipart responses or long-polling ties up a connection to the
server, meaning that you can't issue AJAX calls elsewhere on the page. Additionally, is-
sues arise with proxy firewalls and requests to subdomains.
WebSockets provides the functionality that drove the development of Comet without the
complications. There's no need to use IFrames or generate JavaScript code to be passed
back in a multipart response. With WebSockets both the client and server send data sim-
ultaneously, which can be text, JSON, XML, binary, and so on. There's a well-defined
JavaScript API that's consistently supported across browsers.
One of the biggest differentiating factors between WebSockets and Comet is server-side
support. Java EE 7 introduces standardized WebSockets to the Java platform. There's a
well-defined API with essentially the same callbacks as you see on the JavaScript client.
Comet doesn't have a standardized server-side API, partly because Comet isn't standard-
ized itself. In the next couple of sections we'll dive into the Java EE WebSocket APIs.
14.3. WebSockets and Java EE
Now that you have a basic understanding of WebSockets and how they relate to other tech-
nologies, it's time to dive into the APIs. As we've already mentioned, WebSocket support
for Java is defined in JSR-356. This JSR defines both client and server-side APIs. The
client-side APIs can be used by any Java applications, thus giving JavaFX and command-
line applications the ability to communicate with WebSocket endpoints. The server-side
APIs are only available in Java EE containers.
The WebSocket API is defined in two Java packages:
javax.websocket.*
and
javax.websocket.server.*
. These packages correspond to client and server APIs,
respectively. We'll focus most of our attention on the server APIs.
Before we dive into the server API, we need to spend a few minutes discussing threading
and security. Unlike Servlets, a WebSocket endpoint is created for each client that initiates
a connection. An endpoint is thus stateful and serves only one client. It's possible to over-
ride this behavior by supplying a
ServerEndpointConfi.Configurator
object
that implements the
getEndPointInstance()
method. This method returns an in-
stance of the WebSocket endpoint to be used for a new connection.
