"The basic issue is there isn't enough information in an incoming websocket message for the container to know where to route it if there are multiple methods where it may land."
Danny Coward, JSR-356 lead
In response to question on user mailing list
WebSocket Apps
in Java and Spring
Rossen Stoyanchev
@rstoya05
What is WebSocket?
Sockets have been around
Longer than our careers
java.net.Socket
@since JDK 1.0
What is a "Web"Socket?
Have you ever had to
display "live" data?
... in a browser
Uses cases range
Simple: breaking news, chat
Advanced: financial, games, collaboration
Have we done it before?
- Flash
- ActiveX
- Server-Sent Events
- XHR long polling
- XHR streaming
- etc......
WebSocket Protocol
- RFC 6455
- Finalized December 2011
"Web"Socket in a nutshell
- HTTP handshake request
- Underlying TCP socket remains open
- Bi-directional communication
- Thin layer over TCP --
split byte stream into messages
W3C WebSocket API
- Candidate recommendation since Sep 2012
- Supported in most browsers
- Except on IE < 10 !
- We'll come back to this (don't leave yet)
WebSocket and Java
JSR-356
- WebSocket API for Java
- Spec completed May 2013 (part of Java 7)
- No Java EE 7 servers yet
- However Tomcat, Jetty support it
Before JSR-356
- Pre-existing support in Tomcat/Jetty/Caucho/Grizzly
- All complete re-writes after JSR-356
- jWebSocket -- higher level channels, events
built on Netty/Mina/Jetty/Tomcat - Kaazing -- commercial,
higher-level messaging (JMS, AMQP, XMPP)
After JSR-356
- Convergance of APIs across Servlet containers
- Theoreticlaly not tied to Servlet API
- Will other servers implement it?
- What does it even mean
for higher level APIs (jWebSocket/Kaazing)?
Practically Speaking
- JSR-356 will be in all Java 7 servers
- So it's important to a majority of developers
- Java ecosystem however is wider--
other WebSocket servers - Also with higher level messaging
WebSocket APIs are not what apps use
Current Status by Server
- Tomcat 8 (at RC10) + backport to Tomcat 7.0.47+
(pre-existing Tomcat 7 support removed) - Jetty 9 new (native) WebSocket implementation
Jetty 9.1 adds JSR-356 layer - Glassfish 4 with Tyrus WebSocket engine
- WildFly/Undertow (currently 8.0 CR1)
WebSocket and Spring
The Spring Value-Add
- Spring configured JSR-356 endpoints
- Spring WebSocket API
- Fallback options
- Higher-level messaging support
Spring Config for JSR-356
- Basically use JSR-356 API
- Declare endpoints in Spring config
(skip JSR-356 container scan) - Singleton / per-session instance endpoint lifecycle
- Client-side auto startup mode
Spring WebSocket API
- Adapts to JSR-356 runtime (extends to others)
- A foundation for Spring's own use
- We view it as a low level building block
- Customizable, well-integrated with Spring MVC
Fallback Options
- Emulate the WebSocket API (as close as possible)
- Various transport options underneath
- For where WebSocket isn't supported (IE < 10)
- ... or is precluded by network proxies
SockJS
- A lightweight protocol specified with python test suite
- Browser JavaScript client provided
- Wide range of server implementations available
- Now also supported in
spring-websocket
SockJS Transports
Using SockJS in Spring
- A matter for configuration change
- Code remains the same
- sockjs-client in the browser
- Essential for any public facing application
Building
WebSocket-Style Applications
Using a WebSocket API directly is a bit like
writing a custom Servlet application
Except the WebSocket protocol is
on lower level than HTTP
WebSocket vs HTTP
Using WebSocket API
(Doable but leads to...)
- One WebSocket handler for entire app!
- Custom message formats
- Big if-else loop to interpret messages
- Essentially your own framework (+ client-side)
"The subprotocol attribute of the handshake might serve as a useful place to attach this kind of message description/meta data, or some JSR356 specific headers in the handshake. Of course, the other issue is that the other end is often javascript, which would need to participate in some way in such a scheme."
"These are all things we'll likely look at in the next version."
From next reply on same thread
Sub-protocols
- WebSocket defines sub-protocol mechanism
- Essentially use higher-level messaging protocol
- Either way you've to choose message format:
custom, standard, or framework-specific - ... and clients are impacted by this choice
Messaging Sub-protocol Examples:
JMS, AMQP, XMPP, STOMP, MQTT, VNC, ...
Use Message Broker?
- Actually yes, RabbitMQ, ActiveMQ, many others
- ... support sending messages over WebSocket
- directly from the browser
- RabbitMQ also supports SockJS
Using Message Broker
Why Do It?
- Messaging is a hard problem
- Brokers have been doing it for a long time
- Scalale, robust, configurable, monitaring
- No need to re-invent the wheel
Why Not Do It?
- Message brokers never been used over the web
- We already have a Web application server
- Need web framework centric programming model
- Something that feels familiar to web devs
STOMP
- Commonly supported in message brokers
- Simple messaging protocol
- Frames modelled on HTTP
- Well suited for use over the Web
STOMP Frame
"Destination" Header
- Opaque string, syntax left to server
- Typically path-like URIs (
"/queue/a","/topic/a") - Message brokers choose the semantics
Example
Client Sends Message
Example
Client Subscribes To Receive Messages
Example
Client Receives Message
What STOMP Gives Us...
- A message format .. check!
- Client library like stomp.js .. check!
- Higher-level messaging protocol .. check!
- Good progress everyone (0 lines of code)
STOMP Over WebSocket
Spring Framework 4
Example Controller
@Controller
public class GreetingController {
@MessageMapping("/greetings")
public String greet(String greeting) {
// Return value broadcast to "/topic/greetings"
return "[" + getTimestamp() + "]: " + greeting;
}
}The Big Picture
with Simple Built-in Broker
The Big Picture
with Message Broker
