Apache Camel + WebSockets: Lessons learned

Apache Camel worked well with HTTP protocol but as soon as I needed WebSockets, I realized that Camel WebSocket plugins offered very limited functionality (either only client or server mode not both). I tried working around these limitations by combining different WebSocket plugins (Atmosphere-WebSocket + AHC-WS + Camel WebSocket plugin) but they just weren’t made to support multiple simultaneous connections bidirectionally. Applying the correlation identifier pattern to make Camel work with WebSockets well would require changing existing interfaces.

I tried using Netty and Mina plugins too with no luck. Apparently there are no stable WebSocket codecs for Mina and Mina2. Netty codecs were available but the problem would be to combine handshake decoder and frame decoders – it seemed like too much trouble because I would need to develop a custom Camel Component to accomplish this. All I needed was to pass through all traffic and apply security rules based on cookie header. However, Netty Camel plugin does not correlate the consumer pool connections with the producer pool connections so it would send a packet from one consumer to first available producer without any regard that wrong producer gets wrong consumer data.

Finally, I came to the conclusion that not only my original design was difficult to implement but it was also bad for performance. Routing every packet of data via an intermediate node would undoubtedly add latency and reduce the benefits of using WebSockets.

I thought of using token auth but unfortunately Netty does not support token auth out of the box like Socket.io does. I ended up integrating Netty with Spring Security within a few hours. The whole point of using Camel was to build a secure gateway between services and client-side code (Angular JS). Camel worked great so far for HTTP connections and allowed to keep services stateless as REST services should be, to be easily composable, robust, and quick to load balance. I just need to stress test the set up once everything is deployed to UAT.

WebSockets service composition is an interesting topic and undoubtedly as more WebSocket applications and services appear we will have to have an enterprise-grade WebSocket support in tools like Apache Camel. At this moment, however, it appears that most WebSocket services are oriented for web browsers and not service composition.

Originally posted on Linked In: https://www.linkedin.com/pulse/apache-camel-websockets-lessons-learned-andrew-miller