Film Festivals around the world would love to get instant feedback on the movies that are showcased. A few months ago we learned that current voting solutions fall short. Feedback is neither instant nor simple.

Festival voting is still a manual process. At some venues, festivalgoers tear a corner off of a paper ballot and deposit it into a ballot box. Then festival personnel count, and recount, the votes. Sometimes votes cannot be counted: 2 corners are torn off, a corner is only partially torn, etc. Manual voting slows down results.

We believed there had to be a better way of voting.

Why not develop a real-time system that is secure and reliable? Better yet, why not a voting system where festivalgoers can vote using their smartphone or tablet?

The Palo Alto International Film Festival staff loved the proposal, and this is where the story begins for Instant Film Feedback (IFF). Working closely with the PAIFF staff, we developed the workflow for a real-time voting application that uses Kaazing technology as a foundation for the Mobile and Web communications, and the application experience is completely tailored for the event.

Want to see IFF in action?

But wait, there’s more.

PAIFF and Kaazing also wanted to keep the audience engaged before movies started, so we developed an interactive quiz application where the audience can answer questions and see, in-real time, how much they and their fellow festivalgoers really know about movies. Results are displayed simultaneously on their smartphone and the theater’s movie screen. Why are we so excited about this? Just imagine where else an instant feedback application could be applied?

Real Time Surveys: Imagine the situation where an organization would like to poll an audience by sending tens, or even hundreds, of interviewers into the field to gather a target market’s immediate feedback. As the interviews take place, the organization can get real-time feedback on the answers the interviewers get. Depending on the answers of each individual interviewee, combined with the answers of all others interviews taking place at the same time, the organization can change the flow of questions on the fly to gather better intelligence, tailored to the instant profiling of interviewees. Now that is what I would call real-time adaptive analytics. This of course can be applied to any industry or organization, civil or military.

Real Time Polls: Ever watch American Idol or Dancing with the Stars? We wait days or weeks to get the results of the audience voting. Why wait so long? Would it not be better to open the voting and watch the results stream in right on your TV? If your favorite contestant is falling behind you can pick up your phone and cast your vote right then to turn the tide in their favor.

I can only anticipate that voting would increase tremendously. The show producers may have a different perspective on this. They love to make you linger until the next week. After all their goal is to sell more advertising, but that is a different problem. Of course, we are not advocating any changes that would turn the entertainment industry business model upside-down.

But wait, isn’t that what a disruptive technology does?

Second Screen Experience: Have you ever watched a movie or TV show where you would like to learn more about an actor, a city, or perhaps a product right there as you watch? Or for a football game, have you ever wanted to bet on a Field Goal – when the ball was in the air? This is where we are headed. Some of Kaazing’s customers have built applications that do just that. The interesting part is that there are only seconds before the player kicks the ball and potentially thousands, or hundred of thousands of viewers may want to place their bets. Think of how many millions of people watch the Olympics or the World Cup. Kaazing shines when there are only seconds at play, and a large number of viewers want to interact with a Mobile or Web application.

These are just a few examples on how Kaazing enables new and exciting Web applications that were just not possible using legacy or traditional Web technologies. The world has changed and the depth and range of user expectations have increased dramatically. Kaazing’s technology is scalable, secure and always on, so that companies and organizations can bet their business on it. There is a reason why major global investment banks chose Kaazing several years ago to power their Web and Mobile applications and why the Palo Alto International Film Festival is trusting us to manage real-time voting for the Kaazing Audience Award.

If you are near Palo Alto this weekend (September 27th-30th, 2012) come see IFF for yourself, and you can watch a great movie to two also. If you are not near Palo Alto, be sure to check PAIFF.net. As each movie ends you will see real-time audience voting results. You may learn about a movie that the audience loves.

One of the most frequent questions we answer is about moving from existing Web architectures and how to cost effectively bring dynamic, real-time content into applications. Because all customers have already made a big investment in existing infrastructure there is a reluctance to rip-and-replace. A better goal, be to construct a solution that slowly transitions one into a Living Web. This solution would continue to leverage existing infrastructure and still gain the benefits of the real-time content and instantaneous data flow from all devices.

In order to rapidly transition to a dynamic web, an architecture to consider for new projects is a real-time data service (RDS). Retaining your existing Application Servers for static content you do not tax this infrastructure for real-time functions,. You leverage the RDS to handle the real-time, Living Web components that service your modern (or even better, any) browser and mobile applications. You may choose to offload more and more functions from the legacy components as application features are “brought to life in real-time”. In this fashion, you can gradually transition, in a cost-effective manner, from your costly legacy Application Server infrastructure to a modern Living Web platform.

There is nothing static about an RDS. For example, companies may decide to add real-time functionality for specific events where the message load may peak for only the time of the event. And as more and more applications come online, with Kaazing WebSocket Gateway, it’s easy to scale thanks to a cutting edge load balancing and clustering system that will allow you to grow and shrink your RDS on demand. And of course, one pays only for what one uses.

Messaging has been in use for the purpose of data streaming for many years. However, only recently has the technology become available that provides a way to deliver the data directly to the browser via a protocol more appropriate for the task than HTTP. With HTML5 WebSocket, it becomes straightforward and easy to consume and interact with data streams directly in the browser and on mobile devices.

Customers today demand a live, interactive experience that returns immediate, real-time results and spans across a multitude of devices including browsers, mobile phones and tablets. If a customer facing website or mobile application fails to provide the right level of “stickiness”, customers move on and go elsewhere. Examples of how real-time messaging can drive a strong community presence includes live customer chat, instant support forums, instant notifications of new solutions and the ability for customers to find each other for peer collaboration.

Enabling companies to drive real-time content today while preparing for a wholly dynamic world tomorrow is at the core of a Real-Time Data Service.

The Web is growing at an unprecedented rate, with the number of connected devices climbing rapidly towards an estimated 50 Billion by 2020 while end-users are expecting much more interactivity from their Web and mobile applications than ever before. As the industry attempts to move forward to address these challenges, innovative solutions span across all layers of our Web architecture. Both SPDY and WebSocket work together to provide the most efficient means of communication for our Living Web applications.

SPDY: Optimizing HTTP Request-Response

SPDY aims to optimize HTTP’s use of the transport layer such that many HTTP request-response conversations can flow in parallel between the same browser and Web server, changing the syntax to reduce the number of bytes used to represent each logical HTTP request-response. This is a positive step forward that has a number of technical advantages over direct use of HTTP/1.1.

While SPDY is a protocol that can be used instead of HTTP, it still represents a transparent optimization, so the logical programming model for application developers remains unchanged and the HTTP request-response interaction pattern remains in effect.

There is a significant challenge then to deploy such optimizations over the public Internet where intermediaries are not already aware of SPDY. This is precisely why SPDY leverages TLS to seamlessly navigate through HTTP intermediaries that already facilitate HTTPS end-to-end encrypted conversations.

During the initial TLS handshake, client and server negotiate the use of SPDY instead of HTTP using the TLS extension called Next-Protocol-Negotiation (NPN). Using negotiation in this way allows both clients (browsers) and servers to add support for SPDY independently, without introducing backwards incompatibility for clients and servers supporting HTTP/1.1 only.

Note that in more privately controlled environments, where Web intermediaries can be managed effectively, it would be possible to use SPDY in the clear over TCP as a direct replacement for HTTP, however systems are not typically deployed that way in practice.

SPDY does not aim to eliminate the benefits of Web intermediaries, such as shared Web content caching, but instead to support only authorized Web intermediaries. This effectively introduces a degree of control over Web intermediaries deployed in the public Internet.

WebSocket: Unlocking Event-Driven Web Architecture

WebSocket optimizes the interaction patterns used by Web application developers, such that they are no longer constrained to client-initiated request-response. The WebSocket handshake achieves this by upgrading a specific HTTP request-response to become a full-duplex, bidirectional channel, such that information can be sent in either direction from client-to-server or server-to-client at any time, without being constrained to request-response interaction patterns. The upgrade to a WebSocket connection unlocks the ability to deliver a truly event-driven or message-oriented architecture not only in the privately controlled data center, but also over the public Web to include browsers and mobile devices as first-class participants in that architecture.

Each WebSocket connection starts out as an HTTP request-response, making the end-user authentication and authorization of a WebSocket consistent with HTTP in general. For example, the HTML5 browser sandbox security model defines the trust boundary as an Origin which consists of a protocol scheme, such as http or https, a fully qualified host name, and a port (which may be implicit: port 80 for ws://, and port 443 for wss://). JavaScript code in the browser, including the HTML5 WebSocket API, is constrained to execute inside this sandbox. WebSocket addresses are URLs, such as ws://websocket.org/echo, making them ideally suited to integrate with the browser sandbox security model, unlike raw TCP support offered by browser plugin technologies like Flash, Java and Silverlight.

WebSocket over SPDY: A Powerful Combination

Given the HTTP-centric design of the WebSocket handshake, it fits perfectly within the HTTP-centric focus of running many HTTP request-response conversations in parallel over SPDY. As defined in SPDY version 3, WebSockets can flow in parallel over the same SPDY connection, offering a clean separation of responsibility between the layers. In fact, traditional HTTP request-response conversations and WebSocket connections to the same target Origin can flow over the same SPDY connection.

The SPDY connection itself acts as a secure transport, having established machine-to-machine trust between the browser and the server. Each HTTP request-response, whether or not it upgrades to use WebSocket, establishes end-user trust such that it can act on behalf of the person using the Web application. This separation of security roles is a fundamental difference between SPDY and WebSocket that allows them to complement each other’s strengths without competing.

WebSockets over SPDY represents a significant leap forward for the foundation of our Web architecture. SPDY improves performance, while WebSocket enables bi-directional continuous communication between the client and the server. The two together are giving us the ability to deliver more compelling Living Web applications than ever before, without breaking the bank at the data center.

We live in an era that has seen the creation and explosive growth of the World Wide Web. As much as the Web has grown, it is about to take a gigantic leap forward. The number of devices connected to the Web will be orders of magnitude greater than just a few years ago, and communication across the Web will be instantaneous and scale to Petabytes of data across both browsers and mobile devices..

Are you prepared for the next 5 years on the Web? Is your infrastructure ready?

We have already felt the beginnings of change. The Web is morphing from a static and stale network to a live, interactive, and constantly changing mesh of communication and connectivity, a Living Web. This new Living Web will allow us to interact with our friends and colleagues at levels we couldn’t have imagined 5 years ago, solve business problems that seemed impossible, continue to innovate using the Web as a foundation for new solutions benefiting humanity, accessing systems and share information at levels never seen before.

The Web as we know it today was only the beginning. The Living Web will change everything.

There is a slight problem with this next phase of the Web, and it boils down to a simple matter of physics and computer science. The traditional HTTP Web technologies of the last 20 years won’t take us through the next 10 years. The demands are different, the scales are different, the expectations are different, the depth and range of what users expect are profoundly different, and the stakes are certainly different.

Rather than using existing technology to reconcile what has already happened, the new breed of IT systems must be able to see, evaluate, analyze, and make expert recommendations based on what is yet to be, and they must do so in real time. We believe that the Kaazing approach is the only way to tackle that extreme real-time Web communication future and address the needs of the living Web.

Kaazing is that rapidly evolving and revolutionary Web platform that will change how companies, and their customers, view their online presence, identity, and business opportunities and how they architect and deploy to support their future Web infrastructure and the explosive growth of mobile devices.

We have on our team some of the most sophisticated technologists in the world – helping to solve challenges that are right on the edge of what’s possible today, and to invent and drive new industry standards to address shortcomings of the Web. This technology team developed a new industry technology standard called HTML5 WebSocket. This new Web communication standard is the first major upgrade of the Web since its inception in 1991, by Sir Tim Berners-Lee.

The Kaazing CTO Blog is an opportunity for you to engage in the future of the Web and take part in one of the most exciting and revolutionary changes in the Web’s history.