Support for WebSocket messaging [SPR-9356]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-9356 and commented

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.

---

Affects: 3.1.1

Sub-tasks:

• Enable STOMP over WebSocket support [SPR-10745] #15371 Enable STOMP over WebSocket support
• Create spring-messaging module [SPR-10746] #15372 Create spring-messaging module
• Provide an annotation-based programming model for processing message [SPR-10747] #15373 Provide an annotation-based programming model for processing message
• Add support for sending messages through (full-featured) STOMP brokers [SPR-10748] #15374 Add support for sending messages through (full-featured) STOMP brokers
• Create STOMP over WebSocket sample application [SPR-10749] #15375 Create STOMP over WebSocket sample application
• Add support for sending direct messages to connected STOMP clients [SPR-10750] #15376 Add support for sending direct messages to connected STOMP clients
• Support using the negotiated WebSocket sub-protocol [SPR-10786] #15412 Support using the negotiated WebSocket sub-protocol
• Configuration support for WebSocket and STOMP [SPR-10835] #15461 Configuration support for WebSocket and STOMP

Issue Links:

• INT-1196 WebSocket adapters ("is depended on by")
• SEC-2049 WebSockets support
• Add documentation for the WebSocket and STOMP/WebSocket support [SPR-11115] #15741 Add documentation for the WebSocket and STOMP/WebSocket support
• SEC-2179 Provide Spring Security WebSocket support

50 votes, 60 watchers

[spring-projects-issues]

Sébastien Deleuze commented

Since it seems there is a strong focus (and its great !) in SpringMVC about async support, I think that supporting Websocket (and/or server side events) would be a killer feature for 3.2.

[spring-projects-issues]

Fran Serrano commented

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.

[spring-projects-issues]

Bjorn Harvold commented

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.

[spring-projects-issues]

Rossen Stoyanchev commented

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.

[spring-projects-issues]

Bjorn Harvold commented

Hi Rossen,

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.

Cheers
Bjorn