07 January 2014

WebSockets with Spring4

by Sergi Almar

Presentation is available online here

This is probably one of my favourite presentations in these year's conference. Spring have basically embraced the WebSockets technology and taken it to another level, as usually - making it easier to use, more compatible and as a whole it easy to adopt.

But first - why WebSockets?

In my previous blog posts I already mentioned some of the historical reasons. There is a big demand for bi-directional communication in web applications, whether you are a ...

  • ... collaboration app such as virtual drawing board or a project management tool ...
  • ... a simple chat application or multiplayer game ...
  • ... social application or community board ...

... you would want to make sure events that occur during the interactions of your users are always propagated to them in time, as fast as possible and with as little overhead (and best performance) as possible. Unfortunately technologies have not been catching up with the need for such applications. Polling technologies, Flash, etc. all had their drawbacks that made web apps seem very heavy, have clinky refresh, require too much resources (or in terms of Flash - an entire flash player besides the browser itself). Not only that but they were basically hacks - they were ways to workaround the fact that the browsers were actually only able to poll data and not receive data pushed from the server itself. And to make things worse most of these technologies got slower and heavier with each new client that connects to them.

Then came WebSockets:

  • with full duplex allowing easy bidirectional communication both from and to the server
  • with very small overhead (two bytes indicating start and end of communication, an empty frame being 2 bytes, whereas HTTP requires 1Kb)
  • with built in stay alive capability via ping pong empty frames
  • already supported in most major browsers

The WebSockets handshake is basically the only place where HTTP is required (see slides for an example). After that the client and server start communicating over the ws:// or wss:// protocols. In terms of support client side already has simple and straightforward API to use. On the backend side, in terms of Java, technologies were somewhat lagging, but JSR-356 aims at improving that. There is already a reference implementation on Glassfish and all other containers have started providing their own.

Spring next to follow:

Spring have embraced this new technology and made it part of Spring4. Since this is a new technology they have also provided a fallback - SockJS - in case the clients use older browsers that do not have embedded support for WebSockets. On the side of the Spring-user we would only need to put .withSockJS() when creating a WebSocket connection. What this would do is attempt a connection with a WebSocket-compatible browser and if this fails it would fallback to using the SockJS implementation essentially hiding any details from both the user and developers of the application.

But isn't WebSockets too low-level?

Yes! What we essentially want is a event-driven message-based communication. So Spring started with promoting some of the concepts in SpringMVC to the core level (such as Message, MessageChannel, MessageBrocker, etc.). And then the last piece of the puzzle was STOMP. STOMP gives the semantics over a WebSockets connection, providing a frame model much like HTTP.

At this point you would probably want to take a look at the presentation where there are a lot of code examples of how the communication would work using WebSockets, Spring4 and STOMP. Essentially the result is a lightweight alternative to HTTP which allows bidirectional communication and has some great support on the Java side thanks to Spring. It would be a very good match to build up applications according to what the ReactiveManifesto evangelizes.

03 January 2014

Web apps: a different angle - Web applications in Java with Spring Data, Spring Data REST and AngularJS

by Ioan Eugen Stan

Presentation is available online here

This tech demo session was awesome in terms that it actually utilized quite a lot of technologies without making the sample project a nightmare. Actually, and to my amazement, these technologies stuck up pretty well and allowed the presenter to quickly build up a very nice looking and modular application. Since this was a tech session I will not be able to do anything more than talk about what caught my eye and leave the actual code exploration for yourself.

Spring Data

Since we are building a classical web app we would most probably start with the data layer. Spring provide, in their spirit of achieving simplicity and ease-of-use, the Spring Data project. It a "CRUD on steroids" - as you might have guessed it provides an abstraction from the implementation (JPA, Hibernate, MongoDb, Neo4j, etc.) via a similar API, but not only that - it also provides this magical finders. Simply said - as long as you follow the correct query name pattern when giving names to the methods of your repository Spring will actually generate a query for you leaving you to only deal with the interface part of your repository. Pretty awesome, uh? Of course if you'd like to you could override the default implementation with yours, because, between me and you, we know who is the better programmer, right?

See a very comprehansive example here.

Spring Data REST

HATEOAS - another buzzword in the conference is something that really got me excited. I am still new to the subject, so bear with me, but what I can gather from the concept is that it aims at decoupling the client-server link, especially in REST communication. IT does that by removing the requirement of description languages that would otherwise be used to describe how the service is used (e.g. WSDL, RSDL, etc.) and instead depend on the uniform language. Basically what you do is receive different entities / catalogs as separate URLs and execute actions on them via the HTTP syntax (e.g. GET, POST, etc.). This is really very logical and would really allow the server side to evolve independently from the client side.

See a very comprehansive example here.

Other technologies

There was also a number of interesting frameworks and tools that helped work on this sample project, such as:

  • Spring Shell - could easily explore HATEOAS REST services
  • WebJARS - manage client side libraries explicitly and easily via Java based tools such as Maven
  • Maven Jasmine Plugin - run JavaScript tests similarly like JUnit tests
  • Bootstrap - a large library of ready to use CSS/JavaScript components that are also mobile friendly
  • AngularJS - probably the most discussed UI framework throughout the entire conference, strong MVC, clean data binding, POJO model, encourages nidularity and unit testing

02 January 2014

Real Time with WebSockets

by Andrew Lombardi

The presentation was based on this example of utilizing WebSockets to make bidirectional communication possible

WebSockets was one of the major topics of the conference and, as far as I can tell, a strong buzzword in the community right now. The concept of sending data back from the server triggered not by a user request but by some other event (e.g. the server has finished processing some information) was solved poorly over the past few years, specifically speaking in terms of push technologies. Here is a quick list of some of the solutions (you can read more about them in the link I provided), and some of their characteristics:

  • HTTP pooling - noisy, expensive non-deterministic, but works
  • Long pooling - could easily throttle out of control
  • Streaming - expensive as it does not close the connection until updates arrive
  • HTTP / REST - polling becomes expensive when there are many clients
  • WebSockets - requires only 2 bytes to be sent when communicating

What Websockets gives more than any of the earlier technologies is the very low footprint of the exchanged information and good latency (because this is TCP communication there is no need for an expensive request/response cycle). Be sure to check out the node.js framework - it was refferenced as the de-facto standart.

Last but not least - browsers that do not yet (or will never) support WebSockets could utilize one of the many JavaScript frameworks in order to achieve compatibility - such are the Socket.IO and Sock.JS libraries.

As a disclaimer I will write another article on WebSockets and Spring where I expect to delve in the subject a bit more.