Java Reference
In-Depth Information
One approach to get around the limitations of HTTP request-response is to use browser
plug-ins like Java Applets, Flash, ActiveX, and so on. With these plug-ins, you can do
practically anything because you can open up raw sockets to stream data back asynchron-
ously. But they have several major drawbacks. End users must have the plug-in installed
in their browser, and certain plug-ins, such as ActiveX, aren't cross-platform. In addition,
many mobile browsers have limited support or no support for plug-ins; for example, Flash
isn't available in the standard browser on iOS devices. The plug-ins often take a significant
amount of time to initialize and load. Although fast computers and high-speed internet con-
nections have made this less of an issue, it's still noticeable. Integrating plug-ins into a page
isn't always clean and can be buggy. The biggest drawback, though, is that these technolo-
gies aren't using standard web protocols and the back-end server must be custom-written.
Many corporate networks use proxies that are paired with authentication and port blocking
as a part of corporate security. Non-HTTP traffic out of the company is thus completely
blocked, meaning that an Applet couldn't communicate directly with a back-end server via
a non-HTTP port. These are only a few of the problems that plague the browser plug-in
approach.
Two other approaches taken to get around the limitations of the HTTP request-response
model in the browser are AJAX and Comet. We'll compare each in the following section to
WebSockets, but they aren't a complete solution. AJAX enables asynchronous calls from
the web browser after the page has been loaded to retrieve either a partial page or data
without a full page reload. Data is often returned in JSON (JavaScript Object Notation)
format. AJAX is still a pull—the browser has to initiate the request. To create the im-
pression of server push, many pre-HTML5 web applications coupled polling with AJAX,
which is fine for email applications but not completely acceptable when near-real-time be-
havior is expected.
Comet does support server push. It leaves the HTTP connection open, or open as long as
possible, so that data may be streamed back asynchronously from the server. Comet ties
up a connection in the browser. Because this is a technique and not a standard, it doesn't
have a standard server implementation, and the long-running socket connections can run
into trouble with Enterprise firewalls.
Now that we've covered some of the limits of the request-response model, let's take a fresh
look at the problem through the eyes of a new Java EE standard, WebSockets.