Kaazing Launches WebSocket Platform in Amazon’s EC2 Cloud

It’s the stateful communications protocol that HTTP lacked from the very beginning, and now it’s a key component of the latest versions of Internet Explorer, Chrome and Firefox. The HTML5 debate has cast WebSocket as a future component of every Web browser and every real-time Web app. Now its principal architects at Kaazing are changing the ballgame for developers, launching this morning its Kaazing Gateway HTML5 Edition on Amazon EC2. Suddenly the makers of MMORPG games, stock trading apps and workforce management tools won’t need to run their sessions with on-premise servers and middleware.

You’ve already seen Kaazing push live data to running apps over the Web. That doesn’t seem like a new technology on the surface, and in fact, it’s not. It’s actually a much older technology – session-based, sending characters from hosts to terminals. It’s what real-world applications need to communicate with their servers. But to do it on the Web, you have to retrofit it – and that’s what Kaazing is known for doing.

“HTTP protocol was originally designed in the 1990s as a way to exchange documents. Because of its design, it’s a stateless, sessionless, bidirectional, full-duplex [protocol]. Meaning, it’s a walkie-talkie model,” explains Yuan Weigel, Kaazing’s vice president of marketing, in an interview with ReadWriteWeb. “I talk, you wait; you talk, I wait. And it’s a request/response, meaning unless the client makes a request for you to talk, you cannot come talk to me, the server. That’s just the way the Web was designed.”

The seed for Kaazing as a company grew from its founders original response to HTML5 caretaker Ian Hickson’s call for a two-way, bidirectional protocol that eliminated the need to open up separate HTTP connections for each and every exchanged element of data. First, this deflates the bandwidth consumed by Web apps by more than 90% – a deflation which is absolutely necessary if an “Internet of Things” is ever to take shape.

Second, it eliminates the need for applications servers and much of the back-end middleware (or is it “middle-end backware?”) that’s needed to facilitate messaging between conventional applications. That’s not the best news for IBM, which foresees the entire IoT as a middleware application.

“Today, as you know, app servers sit between the back end and the browser,” Weigel explains, “and the browser only speaks HTTP. The back end speaks whatever TCP protocol – JMS, AMQP, whatever. So by having Kaazing sitting in the middle, it actually allows you to extend data that’s flowing, let’s say, within a JMS system all the way to the browser. There’s no translator that needs to sit in the middle. Imagine you’re at a United Nations meeting, and you can both speak the same language!”

If you’re a Web app developer, you may already know all this. Today’s news of the deployment of Kaazing’s HTML5 WebSocket Platform on Amazon EC2 ups the ante for any serious player looking to capture the future market of inter-device communication. By putting Kaazing on DevPay, a broader base of small developers can experiment with real-time communication for the first time, on a pay-as-you-go basis.

Weigel tells us Kaazing has added some enterprise features to the platform as well, such as single sign-on, load balancing, failover and disaster recovery. It also adds something called WebSocket emulation support, which enables the cloud to work some serious magic. Quite literally, this feature presents WebSocket-like functionality to ancient browsers that are not, and will never become, HTML5-ready – browsers like IE6. “It’s so close that our customers cannot detect a difference between what’s emulated and what’s native,” says Weigel. “So when our enterprise customers choose to deploy a WebSocket-based application, they don’t have to worry about whether this is going to work. They can just code to the standard WebSocket API and not have to worry about the browser at the other end.”

“In the past, developers spend 75% of their time on glue code. How do you communicate from the browser to the application server? What do you send back and forth? And all these things are not the things that make the application or the user experience compelling,” she continues. “It’s simply things that you have to do to make it work in a Web environment. Whereas with WebSocket, because you don’t have to worry about the communication layer, you can now focus on developing really compelling user experiences – the stuff that makes the customer loyal. It really shifts how your company invests in development time.”