X
Business

Kaazing: http is all wrong for interactive applications

Today's Web-base applications need to be both interactive and work in real time. The hypertext transfer protocol was designed as a "call and response" tool to transfer static data. Kaazing thinks that it has a better way.
Written by Dan Kusnetzky, Contributor

Vikram Mehta, CEO of Kaazing, introduced me to his company and its view of why so many Web-based applications do such a poor job of interactive processing. They make people wait unnecessarily. Why? Kaazing believes that it is largly due to the design of the hypertext transfer protocol (http) that is the foundation for all Web traffic. 

http

http was designed back in the 1990s to make the most efficient use of available systems. Client systems would request a page, a Web server would get that request, it would then look up the page, and send back a response. The Web server would then go about its business of answering other requests and forget about the interaction it just completed.

Interactive systems

Today's interactive systems are designed to allow individuals to collaborate with applications to accomplish a set of goals. Many times this means sending an ongoing stream of updates that allow the user to both see the application's progress and  interact with the program.

While this is straightforward when the individual is working directly with an application on his/her client system or when working with a properly designed client/server workload, it is rather difficult to achieve the same thing using http.

The developer has to develop a way to tract the state of the workload, that is, what requests have been made, what have been satisfied, and what work remains to be done. http wasn't designed to make it easy to maintain state or to update only a portion of the screen with new data.

Attempts to resolve this problem

Over time, the IT industry has attempted to address this problem. Many different Web development languages, application frameworks and even libraries of Javascript code have been deployed.

Kaazing's approach

Kaazing's founders thought that it would be wise to step back a bit from http and develop their own network communications protocol for real-time interactive Web applications. The company’s IoT gateway, a software-based web communications platform, was the first step. It was designed to enable mobile users, marketplaces and machines to connect and communicate in real-time, more reliably and at unprecedented scale. The next step was providing a set of tools and access methods so that developers could easily use the new communications platform.

Since sockets have been a standard networking approach in both the UNIX and Linux worlds for a very long time, Kaazing decided that implementing sockets and providing tools that make it easy to develop interactive applications using HTML5 would be the best approach.

Snapshot analysis

As a reformed software engineer, it was a delightful conversation that brought me back to my software engineering days. The approach that Kaazing is taking makes sense, and the demonstration performed very well. The list of companies that have already taken up Kaazing's approach is pretty impressive, too.

Kaazing's approach competes with those offered by quite a number of other suppliers. Each, of course, believes that their own approach is the best for any problem we'd care to name. While Kaazing's approach makes a great deal of sense, it would be best for enterprises needing to develop and support highly interactive Web-based applications to consider Kaazing along side of other approaches.

Editorial standards