The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Kaazing's Ric Smith on WebSockets

6 replies on 1 page. Most recent reply: Feb 13, 2009 11:02 PM by Sean Landis

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Kaazing's Ric Smith on WebSockets Posted: Jan 28, 2009 6:47 PM
Reply to this message Reply
Advertisement

Frank Sommers: WebSockets promises to allow us to bypass the Web server and create fully-duplex sockets between the Web browser and server components. How does WebSockets fundamentally alter how we build enterprise Web applications?

Ric Smith: If you think of how the Web works today, you can think of it as having a walkie-talkie, request-response communication: You click a button and say what you want to say; and then you have to wait for the response in order get something back. There is no way for the server to initiate any kind of communication back to the browser.

A new specification inside the HTML 5 spec, WebSockets, makes a full-duplex connection between the browser and the server possible. The HTML 5 spec is new, and none of the major browsers implement it currently. Our Kaazing gateway and our client-side JavaScript library enable WebSockets to work on existing browsers. Once browsers start supporting this standard, the client-side component of our tool will just use the native browser implementation of WebSockets. If you’re building a Web site, and want to use Web Sockets, therefore, you can do that now.

In a nutshell, then, Web Sockets allows you to have a push-style communication over a single connection. Some of the use-cases we see are interactive games written entirely in JavaScript and HTML; there is also interest in terms of casino-style gaming. We receive a lot of interest from the financial community: applications, such as trading platforms or stock matrices, can get real-time information to the browser using Web sockets.

Our client side library provides an emulation layer that works across the major browser versions. To back that JavaScript API, we have a server, or gateway, that manages the connections and provides a layer of security as well. When you’re accessing this backend directly from the browser, you have a proxy where you can inject your security credentials, and you can scale out all the persistent connections.

Frank Sommers: How does WebSockets compare with similar push-style technologies, such as Comet?

Ric Smith: First, Comet is not a standard. The Dojo community invented it, and it provides bi-directional communication that is limited to a pub-sub model.

Web Sockets, on the other hand, is a purely single-socket model: you’re not using two connections, one for a request, and one for the server to push data. Another big difference is that you’re provided a socket-level API with Web Sockets: You’re dealing with just point-to-point communication. It’s very easy to build a pub-sub type of model on top of Web sockets, so you could have the same interaction you currently have with Comet, if that’s what you wanted. However, Comet doesn’t do point-to-point: You have to create your own meta-channels, and it’s still going to be limited to the pub-sub model.

Frank Sommers: Could you describe how a programmer interacts with the Web Socket’s API?

Ric Smith: As programmer, you open up a text editor and write an HTML file. Then, you open up two script tags, and in those script tags you instantiate a JavaScript object called WebSocket, passing it a URL that specifies the server you want to connect to. That will create the connection. There is a handful of callbacks you can add to that object such as onOpen, onClose, or onMessage. You would then use the postMessage() method on that object to post messages to the server. Once you’ve done that, you are then able to integrate various services with a Web Sockets framework.

There is a small configuration file on the server where you define the services that will be available. Those services, such as Active MQ or a database installation or a Web service, are proxied through the Kaazing gateway. As long as those services are TCP-based, you can declare them as service in the configuration file, and then you’ll be able to reference them via a URL when you instantiate a Web socket.

Another distinction between Comet and Web sockets, by the way, is that the message the back-end service sends in the Web Socket case is the same message that’s received in the browser. In Comet, a translation occurs: the back-end service would push the information to your Comet server, and that message is then translated to a format received in the browser. So Web sockets take out a major translation step, removing significant latency. In the XMPP case, for instance, when Google Talk sends a message, the server sends an XMPP message, in fact.

In a typical scenario, you run the Kaazing Gateway alongside a Web server, such as Apache. Apache still distributes all of your static data, so you could be coding in PHP, or using Tomcat, of instance, and write Java-based services, and along the Apache instance you have our gateway that proxies all of your socket connections. On the client, we have a very lightweight JavaScript library that gets downloaded from our gateway into the client browser.

We have an open-source version at Kaazing.org that you can download under an OSI-approved license. You can also download an evaluation of our enterprise offering. The open-source version provides the same functionality, minus APIs for Flex and some management tools.


Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 2, 2009 4:41 PM
Reply to this message Reply
I am curious how WebSockets addresses two fundamental issues: scalability WRT clients, and statelessness.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 12, 2009 5:10 PM
Reply to this message Reply
> I am curious how WebSockets addresses two fundamental
> issues: scalability WRT clients, and statelessness.

sheesh, hasn't everybody given up on 'statelessness' already? i mean that somewhat in jest, because i like engineering principles -- but i think most live commercial sites do /something/ or other in order to have state. there are principles, and then there's what everybody is doing to make a buck?

Ian Robertson

Posts: 68
Nickname: ianr
Registered: Apr, 2007

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 12, 2009 10:21 PM
Reply to this message Reply
> sheesh, hasn't everybody given up on 'statelessness' already?

Smaller sites use state because it is so convenient, but many high volume sites intentionally avoid server side state because of the scalability challenges it presents. Client side state (such as cookies) can be very useful here. Of course, eventually there is state needed in the database, and there might be a cache layer in front of that which mirrors that state as well, but holding state in the web tier is by no means necessary.

Ric Smith

Posts: 2
Nickname: ricsmith
Registered: Feb, 2009

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 13, 2009 11:17 AM
Reply to this message Reply
Sean,

WebSockets itself does not address scalability. The spec defines the protocol and nothing more. Scalability is really up to the vendor. Kaazing Gateway was built on NIO and leverages a SEDA-based architecture. Through effective async processing of requests we have been able to connect hundreds of thousands of users to a single machine.

State is more dependent on application level protocols than on WebSocket. For example, you can build an XMPP client on top of WebSockets. In this case, the definition of state is defined by XMPP and as such should be handled by the client and the XMPP server that you are connecting to via WebSocket. Therefore, state would be managed on the client (i.e. in the browser) and/or the XMPP server.

I hope that answers your question.

Thanks,
Ric

Ric Smith

Posts: 2
Nickname: ricsmith
Registered: Feb, 2009

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 13, 2009 11:21 AM
Reply to this message Reply
Hi Ian,

You are exactly right. HTML 5 Storage, which is also provided by our emulation layer, provides an efficient means for caching client-side state.


Thanks,
Ric

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Kaazing's Ric Smith on WebSockets Posted: Feb 13, 2009 11:02 PM
Reply to this message Reply
> I hope that answers your question.

It does. Thanks Ric.

Flat View: This topic has 6 replies on 1 page
Topic: Sun's Jeet Kaul on JavaFX Mobile Previous Topic   Next Topic Topic: Java Properties without Getters and Setters


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us