WebSocket

Bozhidar Bozhanov

...one day at home I decided I'm bored => a WebSocket-based game for http://computoser.com

Usecases

● Games● Stock-exchange application● ...anything, really

Why WebSocket?

● Push● Real-time communication● Resource-light● Intuitive, non-hacky

Up to now

● Ajax polling (a.k.a. "are we there yet?")● Long-polling, streaming● Plugins – flash/applets/ActiveX● Problems: hacky, resource-heavy, server-

thread-unfriendly

WebSocket

● Standard (HTML5) ● TCP, full-duplex● More effective on the server-side● High-level protocols ontop – STOMP, WAMP,

etc.

Client-side

● Standard JavaScript API● Browser support – problematic● SockJS, socket.io, fallbacks

Server-side

● node.js● Java – Java EE WebSocket API (JSR-356)● Servlet container implementations – thread

pools● Spring-MVC API, Spring Messaging API

Java WebSocket API vs Spring

● Very similar● One handler per endpoint, differentiate based

on payload● Out-of-the-box dependency injection with spring● No annotation configuration in spring (yet)

Messaging

● Alternative architecture● Using a message broker

(simple/ActiveMQ/RabbitMQ/..) behind spring● STOMP over WebSocket● Client subscribes for events

DDD and TDD

● DDD comes naturally● Objects and their workflows are easily testable● Very few mocks, comparable to spring-mvc

@RequestMappings

Security and authentication

● WSS vs WS (ws://example.com/game)● No same-origin policy. Origin header.● Validate input and output● Authentication – cookies? Cookie-like workflow.

Conclusion

● It's cool :)