The WebSocket protocol has been standardized by the IETF and the WebSocket API is almost standardized by the W3C. A number of Java implementations have become available including servlet containers like Jetty and Tomcat. The Servlet 3.1 spec JSR-340 will likely define the initial WebSocket upgrade request while JSR-356 will define a Java-based WebSocket API.
WebSockets results in a messaging-style architecture, in contrast to a REST-based HTTP architecture, and is arguably much more usable with some additional protocol like XMPP, AMQP, STOMP, etc. There are plans to support it in Spring Integration but there is also room for such support in web applications, support on which Spring Integration could potentially build upon.
If you'd like to see such support added please comment on specific uses cases (or experiences) and requirements for using the WebSocket protocol in a web application. Keep in mind the WebSocket protocol is full duplex and support should be usable on both the client and the server side.
I guess for Spring 3.2 the team had already enough things to consider it worth a release.
Really looking forward to see this working with support from Spring. I've been toying around with Prime-Push (Primefaces) and possibilities explode for performant web applications.
I built a gaming system using Jetty 7.x and CometD 2.x (with Spring). It's an ok stack to work with but there is a lot of room for improvement. Authentication. More control over the json marshaller. Overall, a tighter integration with Spring and Spring Security would make it feel like you weren't working on supporting 2 different controller layers with different requirements.
Bjorn Harvold, thanks for sharing your experience. Cometd provides a number of options for plugging in authentication and authorizations. Were those extension points insufficient or was it just the lack of Spring Security integration? Also what do you mean with the "2 controller layers"? Are you referring to having Spring MVC controllers side by side with Cometd messaging? Thanks for your feedback.
Yes, it's the lack of Spring Security integration. You kinda have to roll your own which I ended up doing by grabbing the Spring Security session from ThreadLocal inside the class that extends cometd's DefaultSecurityPolicy.
Yes, having cometd mappings and spring mvc mappings consolidated would be nice. There is no reason why they can't be unified.
Then it's the BayeuxServer creation which is a little bit of a hassle. I'd say if you're used to @Bean annotation it's ok but there is definitely room for improvement. Look at the Configurator class on the cometd site to see what I mean.
Also, keeping cometd and jetty versions in sync was a bit of a problem for me. Updates kept on breaking the internals and I would have to stay put on older versions of Jetty.
All that said, the frameworks were robust enough to allow me to create a full featured game...but I am very excited to see what you guys are going to come up with.