Posts tagged WebSocket
Kaazing Launches WebSocket Platform in Amazon’s EC2 Cloud
Apr 20th
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.”
View full post on ReadWriteWeb
Is Microsoft Challenging Google on HTTP 2.0 with WebSocket?
Mar 28th
Back in 2009, Google began an industry discussion about a prospective upgrade to HTTP protocol – the application that enables the Web over the Internet. The concept is called SPDY, and to date, conventional wisdom held that while some are skeptical of Google’s motives, as a concept, SPDY was running unopposed.
Maybe not any more. This week, Microsoft is embarking on a curious strategy that sounds a lot like its old “embrace + extend” approach to world domination. Advancing just the introductory paragraphs of an IETF technical proposal that has yet to be released, Microsoft is calling for the next version of HTTP to include multiplexing for multiple components (like SPDY) and full-time encryption of the session layer (like SPDY, but without relying solely on SSL or TLS). The “extend” part comes by way of an allusion to WebSocket (which has recently been considered a part of HTML5) – a provision for full-duplex communications critical to the next generation of Web apps.
Sponsor
Does the Web Need “S+M?”
The introductory paragraphs include the following: “HTTP at its core is a simple request-response protocol. The [IETF Network] working group has clearly stated that it is a goal to preserve the semantics of HTTP. Thus, we believe that the request-response nature of the HTTP protocol must be preserved. The core HTTP 2.0 protocol should focus on optimizing these HTTP semantics, while improving the transport via a new session layer. Additional capabilities that introduce new communication models like unrequested responses must be treated as an extension to the core protocol, and explored separately from the core protocol.”
Employing both multiplexing and encryption on the session layer would, nearly all reasonable Internet engineers agree, dramatically improve the integrity of Web interactions and radically reduce traffic generated by pages that pull their content from multiple sources (which pretty much encompasses the majority of pages). There isn’t much to dispute about Google’s SPDY proposal, except perhaps the use of SSL (depicted in the Google diagram at right) for the encryption – in the wake of vast improvements on the part of TLS.
So if WebSocket is something the Web browser community has been working to implement anyway, what exactly is Microsoft’s motive for attaching WebSocket (or at least, a reference to WebSocket, depicted below) to its counter-proposal for HTTP 2.0 to the Internet Engineering Task Force? Normally a look at the technical breakdown of the draft would yield clues. But as of now, that section of the public part of Microsoft’s draft remains blank.
“The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol (a separate submission to the IETF for this discussion) and the work the industry has done around WebSockets,” states Jean Paoli, Microsoft’s much respected interoperability manager, in a blog post earlier this week. “SPDY has done a great job raising awareness of Web performance and taking a ‘clean slate’ approach to improving HTTP to make the Web faster. The main departures from SPDY are to address the needs of mobile devices and applications.”
That’s the “Mobility” part of Microsoft’s version of HTTP 2.0, and it’s the part that gives the proposal the unfortunate abbreviation “HTTP S+M.” ReadWriteWeb has contacted Microsoft with questions about its intent for the Mobility part, and was told a final response may be forthcoming.
This Page Intentionally Left Blank
Other parts of the public portion of Microsoft’s draft proposal read like an argument than a specification. For example: “There is no ‘one size fits all’ deployment of HTTP. For example, at times it may not be optimal to use compression in certain environments. For constrained sensors from the ‘Internet of things’ scenario, CPU resources may be at a premium. Having a high performance but flexible HTTP 2.0 solution will enable interoperability for a wider variety of scenarios. There also may be aspects of security that are not appropriate for all implementations. Encryption must be optional to allow HTTP 2.0 to meet certain scenarios and regulations.”
One of the long-time problems with Web session encryption is that it tends to be used only in important transactions. Thus the very fact that a session is encrypted generally tells you it should be. Encrypting everything would make it impossible for a sniffer to judge, just from the nature of the stream, what traffic is likely to contain important data.
Here, Microsoft appears to suggest that such a feature may optionally be turned off, perhaps to reduce power and time consumption on smaller devices, and perhaps to enable more “Internet of Things” scenarios. But some would argue that HTTP is an inappropriate protocol for inter-device communication anyway – that an IoT would not necessarily be a Web-of-Things.
Then there is the issue of client/server style communication. As you might imagine, one of the companies making inroads with WebSocket (singular or plural, depending upon whom you ask) is Microsoft itself. But by bringing up a W3C application-layer protocol – one which is likely to be fully adopted anyway – in the context of an IETF transport layer technology, is Microsoft’s goal really to expedite this discussion or to slow it down… like it did once before?
HTTP 1.0′s deficiencies and omissions are legendary, and its usefulness in the modern realm of Web applications has come only with substantive effort. The need to replace HTTP 1.0 was recognized by cooperating members of the IETF from the time the Web began.
But the first, best chance at upgrading HTTP with an object-oriented protocol geared toward apps came and went in 1999. HTTP-NG, as it was called at the time, ceased to be discussed not long after some of its creators were hired into Microsoft Research. A technology that would have enabled Web applications a full decade-and-a-half before the form factors for such apps were even fleshed out, stalled for lack of momentum – all in the interest of “open discussion.” There’s a danger here that Microsoft’s move could cause the latest incarnation of HTTP 2.0 to suffer the same fate.
Stock image by Shutterstock
View full post on ReadWriteWeb
