I haven't played around with websockets yet, so most of what I know is theoretical.
You have to use sockets to talk websocket, because, well, it's web
socket. Whether you code for raw sockets or via an abstract API, there will be a socket in there somewhere on the client talking to the websocket on the server.
Any program can talk to a webserver as long as it addresses the proper ports and uses the proper protocols. It doesn't have to be a browser app. I use telnet for basic diagnostics, for example. A number of stand-alone java applications serve as
test runners for web testing. Adding websocket protocol to a client doesn't change that ability.
Stepping back specifically from websockets, one of the major predecessors to websockets is RMI. RMI is an efficient way for 2 or more Java apps to communicate privately in a conversational mode using simple Java method invocations for APIs that you design. It serves as the underpinning for
EJB remote objects, which are part of the core J2EE spec, although not natively implemented in Tomcat.
The primary advantage of websockets over RMI is that they aren't limited to java-to-java app communication and that they operate under web protocols.