Java Reference
In-Depth Information
The current solution that includes trying to simulate real-time data delivery using HTTP
protocol can put a lot of stress on the web server. Polling (asking the server about up-
dates), long polling (delaying the completion of a request to the moment when an update
is ready), and streaming (a Comet-based solution with a constantly open HTTP response)
are all ways to hack the protocol to do things that it wasn't designed for and have their
own limitations. Thanks to the elimination of unnecessary checks, WebSockets can heav-
ily reduce the number of HTTP requests that have to be handled by the web server. The
updates are delivered to the user with a smaller latency because we only need one round-
trip through the network to get the desired information (it is pushed by the server immedi-
ately).
All of these features make WebSockets a great addition to the Java EE platform, which
fills the gaps needed to easily finish specific tasks, such as sending updates, notifications,
and orchestrating multiple client interactions. Despite these advantages, WebSockets are
not intended to replace REST or SOAP WebServices. They do not scale so well horizont-
ally (they are hard to distribute because of their stateful nature), and they lack most of the
features that are utilized in web applications. URL semantics, complex security, compres-
sion, and many other features are still better realized using other technologies.
