WebSockets with Apache Tomcat and HLL

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
I announced the HLL WebSocket Server Demonstration in September, 2011. Since then, it's been running full-time on an old Acer notebook that currently resides out in the hallway. (This time on Ubuntu Linux.)

The web page involved in the demonstration had been served from somewhere in California from a 24/7 hosting site, which I've recently decided I don't want to pay for anymore. So, I installed Tomcat 7 on the little Acer machine to serve the content I had remaining there, including the WebSocket demonstration web page. And there you have it. Tomcat is working with WebSockets all on the same machine. Just what everyone has been waiting and hoping for.

The irony is that HLL was designed to connect from anything to anything else, no matter where the various components are in the world. It works just as well if one machine is in Singapore and another in Stockholm. Of course, two components on the same machine are going to interact faster on average. But it really doesn't otherwise matter where the http server is or what brand of server it is. As it is, my HLL WebSocket server components are not installed under Tomcat, even though they're on the same machine. The demonstration provides a websocket connection between the client browser and the websocket server. So seriously, it doesn't matter where the http server is that provides the web page to begin with.

And of course, since it's all based on a real-live standard, any real WebSocket system can talk to any other real WebSocket system. So, if there are eventually some web app components using Apache technology, they can as easily communicate with HLL WebSocket connections as their own and vice versa. (I've also been considering support in HLL for the FIPA standard for message content. Who's with me? -high-five! ... along with other options.)

My heavy interest in WebSockets is directly related to HLL. WebSocket components can reside anywhere and talk with components anywhere else. They don't need to reside under an http server. I've been doing that type of communication for years between web app components. What I really needed was a standard approach supported by browsers. WebSockets Rock! And since my WebSocket server starts with a gateway process, I'd be just as happy using that to pass requests to Tomcat rather than the other way around. (Very fast gateway. You wouldn't notice the difference, especially on the same machine or even in the same LAN.) With HLL configuration, the whole idea is a piece of cake.

Nonetheless, I would like to make it easy for myself and other application developers (associated or willing to hire me, or fund me in some way) to use WebSockets in a very flexible way. I think they're great. One of those ways will be to install my WebSocket client (see note below) to be shared across all web applications, making it very simple to initiate a WebSocket connection from a servlet or other webapp component. I'll do that when I have time, which won't be this month, or sooner if someone steps up and offers the right price. :)

Note: We have to be careful about using the terms “client” and “server” when talking about WebSockets.

I assume it makes sense to people who've been through the same initial tutorials that I have. You've probably first learned that a browser initiates the connection pretty much like it does with http. The “server” responds and then you have a bidirectional connection for as long as you like.

But once you get past that, and very quickly indeed with any out-of-browser experience, and realize that there is no longer a master-slave relationship between the two ends of a WebSocket connection. A stand-alone “client” (if I can lean on that term at least once more) written in Java, for example, should contain the same technology as the “server” and thus can as easily act like one. You can have communication between two such “clients” passing information back and forth as needed.