Tim Moores wrote:Evgeny is asking about web sockets, though, not web services.
Which is why we ask people to avoid using abbreviations and acronyms where reasonable. I think I counted 6 entirely different definitions of the acronym "CRA" in various IBM program products once. Avoiding ambiguity is the first step towards problem resolution.
Ultimately, every URL-triggered process in a web application goes through a servlet. Either an explicit servlet, a
JSP compiled into a servlet, a framework servlet, or (at least in the case of Tomcat), the server's built-in Default Servlet. Servlets can, of course, communicate with non-URL processes, such as batch services initiated and/or managed from the ServletContextListener, in which case the URL requests are indirect, but still a "servler" communicates with the background process.
If I haven't forgotten too much on the topic, a Websocket is based on having the webapp initiate a network connection as opposed to the traditional approach of being the target, and I seem to recall some examples where that was done by handing over to batch services, since process may take a significant amount of time.
The key consideration is that a servlet should be something that receives a request and returns a response as fast as reasonably possible. Anything that would cause an extended delay - websocket or otherwise - should be handed off to a backend process.