• Events
  • Blog
  • W3C
Kaazing in action
websockets.org

Frequently Asked Questions

This document attempts to answer your frequently asked questions and it contains the following sections:

General Questions

This section contains general questions about Kaazing and Kaazing WebSocket Gateway.

What is Kaazing WebSocket Gateway?

Kaazing WebSocket Gateway is a high-performance, full-duplex WebSocket Server. It is the world's first enterprise-ready implementation of the HTML5 Communications specification, which is a standards-based alternative to Comet and Reverse Ajax for real-time communication over the Web. In addition to the server, there is a client-side component that allows browsers and non-browsers to communicate with Kaazing WebSocket Gateway.

What are the primary features of Kaazing WebSocket Gateway?

Kaazing WebSocket Gateway provides a high-performance WebSocket server that enables direct TCP connectivity over the Web. Kaazing WebSocket Gateway also provides a set of client libraries for HTML5 Communications and a set of protocol-specific libraries for various client technologies (for example, Stomp and AMQP). Kaazing WebSocket Gateway includes additional enterprise-ready server extensions such as enhanced security and protocol validation.

My Java application already tunnels through port 80. Why do I need Kaazing?

Most enterprises deploy several applications to their users. Some of them use a Java Virtual Machine, while others are based on Adobe Flex (Flash), JavaScript, or Silverlight. From a management perspective, keeping the network stack consistent across all the applications and all the programming technologies is a big win. Consistency reduces the complexity and reduces the management costs. Using Kaazing for all the applications guarantees that all your applications will get through any firewalls or proxies between your users and the back-end services through a logical set of pipes.

I deploy Java applications with Java Web Start. Why should I be interested in Kaazing?

Certainly Java Web Start has been a useful deployment tool for Java programmers, but it is an independent tool from WebSocket and Server-Sent Events (SSE). If a Java program needs to access a service over the Web using WebSocket, it needs a Java package that implements that protocol (just like normal sockets).

How secure is Kaazing WebSocket Gateway?

Kaazing takes security very seriously. Kaazing WebSocket Gateway provides several mechanisms for secure connectivity from end to end. This includes secure WebSocket (websocket + TLS/SSL), W3C Cross-Origin Resource Sharing, single sign-on, credentials injection, encrypted keyring API, and other security features. Also Kaazing WebSocket Gateway integrates with JAAS, supporting pluggable authentication modules. For more information, refer to Kaazing Security Overview.

Is Kaazing WebSocket Gateway a messaging system?

Kaazing WebSocket Gateway is not a messaging broker. But it works in conjunction with existing messaging systems. For example, Kaazing WebSocket Gateway can be deployed in an existing JMS project without disrupting the existing messaging topology. Kaazing WebSocket Gateway can also be used with other TCP services, not just JMS.

Doesn't Comet already handle real-time communication over the Web?

Comet is a loose collection of techniques to asynchronously push "real-time" data over the Web. It includes mechanisms and protocols on the server and client side. There are no formal standards for Comet implementations. Comet implementations typically employ a second HTTP connection for bi-directional communication between client and server. The HTML5 Communications standard, and specifically WebSocket, addresses the shortcomings of Comet for developers and users who have a need for true bi-directional, real-time communication over the Web.

Does Kaazing use the Bayeux protocol?

No. Most Comet implementations rely on the Bayeux protocol, which requires messages from the origin to be transformed to conform to the Bayeux protocol. This transformation introduces unnecessary complexity in your system, requiring developers to manipulate one message format on the server (for example, JMS, IMAP, and XMPP) and a second message format (for example, Bayeux or JSON) on the client. Bayeux also introduces an unnecessary performance overhead to your system by forcing a message to be interpreted and processed prior to being sent over the wire. With WebSocket, the message sent by the server is the same message that is delivered to the browser, eliminating the complexity and performance concerns introduced by transformation code.

Don't chat protocols like XMPP and Jabber already handle real-time communication over the Web?

Typically, Web-based chat systems are implemented through client-side polling. Polling is inefficient in computing resources both on the client and on the server, particularly when no data is available on the server. While it seems real-time to the user, there are many additional (and unnecessary) computing resources working 'under the hood' to make this happen.

I already get real-time updates in Google Finance, Yahoo Finance, Twitter, and Facebook. Why do I need Kaazing?

Most Web sites that offer "real-time" data typically leverage high-frequency client-side polling, server-side long-polling, or some sort of HTTP streaming. Many of these sites either use computational expensive Comet solutions or have implemented proprietary solutions for real-time Web communication. Kaazing WebSocket Gateway is a very scalable and high-performance implementation of HTML5 WebSockets which offers the same real time updates while using a standards-based technology instead.

Is Kaazing a Web "push" vendor? Didn't we see this movie before in 1999?

Kaazing supplies an implementation of the HTML5 Communications standard, which includes Server-Sent Events (SSE), an efficient non-polling mechanism to deliver downstream data. Kaazing WebSocket Gateway provides many other features beyond simple push such as bi-directional support, secure cross-origin access, inter-document messaging and other enterprise features. During the dot-com era, there were several "real-time Web" vendors.
Most of them either leveraged HTTP headers to send the payload or they required mini HTTP-servers to be installed at Web endpoints, which resulted in efficiency or enterprise constraints.

I have a secure Virtual Private Network for my customers, why do I need Kaazing?

You may have real-time requirements to or from browsers in your Virtual Private Network (VPN). You may also want to extend certain TCP-based services to new customers or partners without involving the complexity of a secure VPN.

How secure is cross-site scripting with Kaazing?

Before HTML5, browsers enforced a "same-origin" access policy to avoid cross-site scripting attacks. By implementing cross-origin resource sharing, Web applications that use Kaazing WebSocket Gateway can now access content that could theoretically have a different domain, scheme, host, or port. Rest assured, however, Kaazing is as paranoid about security as you are.

Kaazing WebSocket Gateway aggressively secures content. The server component is secured using a "white list," which means that each gateway service is by default denied access to cross-origin content. In addition, Kaazing WebSocket Gateway's cross-site JavaScript bridge component implements the new W3C Cross-Origin Resource Sharing specification.

I am a cloud services provider and need to provide real-time services to my customers. Can I use Kaazing WebSocket Gateway?

Certainly. Kaazing WebSocket Gateway is a very useful tool for cloud service providers, particularly SaaS and PaaS vendors. By leveraging two Gateways, one converting TCP to WebSocket and the other converting WebSocket to TCP, a private network can be implemented using standard Web technologies.

How does Kaazing help me move towards HTML5 browser standards?

The HTML5 standard represents a huge and exciting change for the Web and web applications. A key component of this new generation of applications is the network stack that includes WebSocket, Cross-Origin Resource Sharing, Server-Sent Events, and Cross-Document Messaging. These are powerful HTML5 features with game-changing functionality for both browser and desktop applications.  

While many enterprises can control the versions of browsers on their internal desktops, and perhaps even their clients' desktops, there is no guarantee that all end-users are using a WebSocket-compliant browser. Kaazing's client-side technology allows older installed browsers (including Internet Explorer versions 6, 7, and 8 and Firefox versions 2 and 3) to completely participate in a standard WebSocket conversation both at the API level and the wire protocol level, which makes your web applications interoperable with other WebSocket-compliant servers. By using Kaazing WebSocket Gateway, your applications will work (and work efficiently) with practically all web browsers that your customers use. By using an industry standard API and wire protocol, your investment is preserved and your application is future-proofed.

How is Kaazing's WebSocket Gateway different from other servers that support WebSocket?

Kaazing WebSocket Gateway is an enterprise-class product and is designed for commercial-grade applications. Kaazing makes every effort to create a very high-performance and highly reliable product that scales to extreme numbers of users and connections. In addition, Kaazing WebSocket Gateway provides protocol validation and security, single-sign on across domains, connection-offloading for enhanced scalability, a plugin architecture for enterprise entitlements, proxies to other TCP-based protocols and more. Besides our rock-solid product line, we offer enterprise-grade support that is used by our global financial services customers.

This is only the beginning of the real-time Web, we have much more planned!

Developer's Questions

This section contains questions about developing applications with Kaazing and Kaazing WebSocket Gateway.

What programming languages are supported by Kaazing WebSocket Gateway?

Kaazing WebSocket Gateway's client-side APIs are implemented in accordance with the HTML5 Communications standard. Kaazing WebSocket Gateway provides libraries for the following client technologies:

  • Javascript
  • Java/JavaFX
  • Adobe Flex (Flash)
  • Microsoft Silverlight.

In addition, Kaazing provides publish and subscribe APIs for these client technologies that allow them to communicate with standard back-end message brokers such as JMS, Tibco EMS, and IBM WebSphere MQ (MQSeries).

Can native Java applications use Kaazing?

Yes. Java applications accessing cloud services over the Web is a common use case.

Does Kaazing support Microsoft Silverlight?

Yes. Kaazing WebSocket Gateway supports Silverlight applications written in any .NET programming language such as C# and Visual Basic.

Can I embed Kaazing WebSocket Gateway in my Java program?

At this time, the WebSocket Gateway is not designed to be embedded in a Java program as a server-side process.  For developers interested in an OEM relationship with Kaazing, please contact our sales office at sales@kaazing.com for more information.

Do you support JMS?

Both the current client libraries and Kaazing WebSocket Gateway itself support Stomp. Stomp is a popular text-based interface to JMS message brokers. For example, you can use the Javascript Stomp API to talk to Kaazing WebSocket Gateway, which in turn will talk to any JMS-compliant message broker such as Apache ActiveMQ or Tibco EMS.

Which browsers are compatible with Kaazing client libraries?

Refer to Release Notes for an overview of the certified browser versions for this release.

I would like to send compressed or encrypted, binary data. How can I send that using WebSocket?

Kaazing offers ByteSocket client library in addition to WebSocket. ByteSocket allows binary data to be sent over the Web.

Where can I see some example code?

Kaazing WebSocket Gateway comes with documentation that includes tutorials complete with example code.

What data formats does Kaazing WebSocket Gateway support?

Kaazing is data-format-agnostic. Our client library will deliver the same bytes that are sent by the server. No additional processing is performed on the data, so you are free to use any libraries or utilities to convert or parse the data.

What are the best practices to build applications that send structured data such as CSV, JSON and XML to and from browsers?

Our recommendation for performance reasons is use the most minimal data framing available, so something like CSV would be effective. A simple browser-provided Javascript or Adobe Flex (Flash) method can parse the data into a structured form.

I have my own TCP-based protocol. How can I get Kaazing WebSocket Gateway to understand my protocol so I can use it over the Web?

The Kaazing documentation contains a tutorial about writing your own protocol client library.

How do you direct an incoming message in Javascript to a specific HTML component (a tab or a frame, for example)?

Kaazing provides the data from the JavaScript client to the application via a JavaScript function callback. The implementation of that callback function is part of the application and can leverage any toolkit or DHTML technique to update the HTML components on the page that represent the user interface of the application.

How many sockets are opened between the browser and Kaazing WebSocket Gateway? And how many if cross-origin messaging is used?

Same-origin and cross-origin connection profiles are identical. One persistent connection is required from browser to Gateway. This will either be a full-duplex, bidirectional WebSocket connection, or a (possibly encrypted) HTTP downstream. In the second case, upstream traffic is sent on-demand over a second HTTP connection. Kaazing uses SSE on this second connection, so no polling is used at all. With cross-origin facilities, Kaazing software allows many sockets to be opened within the browser, each socket connecting to a different domain.

Which version of AMQP do you support?

The Kaazing AMQP client libraries are compatible with AMQP version 0-9-1.

What happened to the Centurion, Dragonfire (and so on) releases?

The following table maps previously-used Kaazing product names with the current release numbers used throughout the product and documentation.

Previously Used Product Name Kaazing WebSocket Gateway Release Number
Atlantis 8.09_x
Battlestar 8.12_x
Centurion 9.03_x
Dragonfire 9.06_x
Excalibur 2010.05_x

Administrator Questions

This section contains general questions about installation, deployment, and administration.

What are the hardware and software requirements for Kaazing WebSocket Gateway?

Refer to Getting Started for a list of the system requirements.

How do I install Kaazing WebSocket Gateway?

Refer to Getting Started for more information about the installation process. Installing and running Kaazing WebSocket Gateway is quick and easy--You can have it up-and-running in less that 10 minutes.

Do you require browser plug-ins?

No. Our client libraries for browser technologies use a cascading algorithm to find the best networking stack to connect to the server. If your browser already supports WebSocket, our libraries will merely be a thin abstraction over that native implementation. If you have an older browser with the Flash plug-in, our libraries will use that networking stack. If you have a JVM installed in your browser, our libraries will use the java.net stack. If none of these are available, a small (75k) Javascript library is uploaded to emulate WebSocket using two connections so all your Kaazing-based applications will still work. But even in this worst case, the upstream connection will use our Server Sent Events (SSE) implementation which is essentially Comet without polling.

What is the impact on my networking infrastructure if I use Kaazing and do I need additional firewalls and proxies?

Kaazing is extremely efficient at handling real-time communication using a Web infrastructure. If your firewall/proxy hardware is from a reputable vendor, there should not be a need to modify your hardware. Of course, once users are accustomed to real-time data in their Web applications, your user community will soon be clamoring for more real-time applications.

Where are the credentials stored?

Credentials are safely stored in an encrypted cookie value (in the browser). Furthermore, the Kaazing Keyring Service can be used to create new encrypted tokens to access backend services. These encrypted tokens provide additional security, because they have a very short life span (typically less than a minute), which minimizes opportunity for token theft, yet maintains a stateless server implementation for horizontal scalability.

Which version of Java is required to run Kaazing WebSocket Gateway?

Refer to the Getting Started for more information about system requirements

Where can I download the Adobe Flash/Flex libraries for Kaazing WebSocket Gateway?

These libraries are included with Kaazing WebSocket Gateway.

Kaazing WebSocket Gateway will not start when I try to run it. What am I doing wrong?

Make certain that the JAVA_HOME variable is set in your environment. Also, verify that you meet all the system requirements outlined in Getting Started.

I can't access Kaazing WebSocket Gateway at the default URL, http://localhost:8000

The most common problem occurs when another Web server or process is already using the default port 8000. This is the default HTTP port that Kaazing WebSocket Gateway attempts to bind to at startup. To change this, perform the steps outlined in this troubleshooting section.

Why do I receive "localhost is not found" when I try to access http://localhost:8000?

It can happen that localhost is not found when you try to access Kaazing WebSocket Gateway. This can happen if your browser is configured to use a proxy server. If this is the case, make sure your proxy configuration bypasses the proxy to access localhost.

How do I configure Kaazing WebSocket Gateway for optimal security?

This is described in detail in Kaazing Security Overview.

Can I integrate Kaazing WebSocket Gateway with an existing Web application server (for example, Apache)?

Yes. This is described in detail in the Administrator's Guide.

What are the best practices to fully authenticate users and have a secure conversation using JMS?

In addition to WebSocket, Kaazing WebSocket Gateway offers WebSockets over TLS/SSL, which is similar to the HTTP-HTTPS relationship. The transport layer can be secured using the WSS facilities as documented in our Administration guide. Refer to the Administrator's Guide for more information on how to configure this.

Kaazing provides built-in login modules for file-based security and LDAP, but you can also plug in any module which conforms to the Java LoginModule API by including a section in the gateway-config.xml file.

Since Kaazing WebSocket Gateway leverages the popular Stomp interface to messaging servers, you can use the Stomp libraries for login. Specifically, the Stomp client libraries provide direct APIs for including user names and passwords in the browser, which is relayed all the way to the backend messaging server.

My messaging server does not support Stomp. What can I do?

Kaazing WebSocket Gateway provides the Stomp-JMS adapter. Refer to the Administrator's Guide for more information on how to configure Stomp-JMS adapter integration.

How do I use SSO (So I only have to log in once and not multiple times for each protocol I access)?

Kaazing WebSocket Gateway offers a keyring service for this purpose. You can use a keyring to store the credentials to avoid re-authenticating each time a service is accessed. The keyring uses the PKI (Public Key Infrastructure). With the encrypted keyring, credentials can be stored in an encrypted format, decrypted on Kaazing WebSocket Gateway server and dynamically injected into the protocol communication. Refer to Kaazing Security Overview for more information.

What level of encryption is supported by Kaazing WebSocket Gateway?

Kaazing WebSocket Gateway uses Java 6, which supports providers for many of the most commonly used cryptographic algorithms.

What management tools are available with Kaazing WebSocket Gateway?

Kaazing WebSocket Gateway leverages Java Management eXtensions (JMX) to monitor its behavior. Refer to the Administrator's Guide for more information about monitoring.

Do you support Transport Layer Security?

Our Gateway supports Transport Layer Security (TLS) or SSL by providing Secure WebSocket (wss). WS/WSS is similar to the HTTP-HTTPS relationship. By default, WebSockets use port 81 and Secure WebSockets use port 815. But you can configure Kaazing WebSocket Gateway to use port 80 (and port 443). You can specify wss instead of ws in the URI of your target service in the configuration file gateway-config.xml.

Do I need to open new ports on my firewall to enable Kaazing WebSocket Gateway?

This is not necessary. Kaazing WebSocket Gateway provides a full-duplex communications channel that operates over a single socket and traverses firewalls and routers seamlessly. However you can configure Kaazing WebSocket Gateway to use other ports for WebSocket and Secure WebSocket.

How do I architect my Kaazing WebSocket Gateway topology for global deployment?

Kaazing WebSocket Gateway is fully compatible with any deployment topology of a given global architecture. It can be deployed at global nodes along with distributed messaging brokers or any other TCP service. Gateways can be connected to each other to minimize the number of connections needed between the service and the client application.

How do I setup Kaazing WebSocket Gateway for high-availability? Does Kaazing WebSocket Gateway work with load-balancing appliances?

Kaazing WebSocket Gateway works perfectly well with conventional HTTP load balancers, for example, F5, HydraWeb, and Coyote Point.

How do I use multiple Kaazing WebSocket Gateways to setup a remote publish/subscribe architecture?

Kaazing WebSocket Gateways are architected to be used in a TCP-WebSocket mode or a WebSocket-TCP mode.You can also connect one Gateway in one mode to another Gateway in the opposite mode (forward and reverse gateways), essentially setting up a TCP-TCP connection over the Web. For TCP-based protocols that Kaazing WebSocket Gateway is aware of, this feature allows a high-performance, virtual private socket connection across the Web. This powerful feature allows cloud SaaS/PaaS providers, financial services companies and other enterprises to extend their functionality directly to their customers and partners using a cost-effective Web infrastructure.

In a forward and reverse gateway setup, how would DNS find the endpoints on the "other" side of our Gateway?

The quick answer is there is no DNS involved. There are mappings in Kaazing WebSocket Gateway configuration that specify the actual servers and services. In a remote pub/sub use case, both the service provider (for example, a prime brokerage or a cloud SaaS/PaaS provider) and the customer (for example, a hedge fund, supply chain, B2B) need to cooperatively configure each of their Gateways to allow remote pub/sub.

The provider side publishes via their message broker through Kaazing WebSocket Gateway, over the Web, to the other Gateway and to the remote broker. The provider's configuration indicates the remote Gateway. The remote Gateway's configuration (the customer side) specifies the incoming connection and its ultimate service endpoint (the customer's message broker). After that, the customer's responsibility is the same as usual in a non-Kaazing setup; they need to configure their message broker's user access (for example, who can sub). A similar (and symmetric) configuration is needed for a bi-directional relationship. For example, if the customer wants to publish to the provider. These relationships can be expressed in a few lines in the gateways' configuration files.

How can the remote publish/subscribe use case work? Aren't JMS implementations incompatible?

One issue that usually comes up with connecting different JMS implementations (even without Kaazing WebSocket Gateway) is the lack of a JMS wire protocol. Clearly this results in incompatibilities with JMS vendor products. For example, the publisher uses Apache ActiveMQ and the remote subscribers use Tibco EMS. You can address this issue with our JMS-Stomp and Stomp-JMS protocol converters.

Is my network infrastructure taxed more heavily when I deploy Kaazing WebSocket Gateway as opposed to Comet and AJAX?

Kaazing WebSocket Gateway minimizes the overhead of getting raw data from Gateway to browser, with significantly less traffic than traditional Ajax and Comet solutions.

What's the impact on the corporate firewall/proxy infrastructure when Kaazing WebSocket Gateway is employed?

If a customer has 100,000 or greater socket connections open thru the firewall/proxy, how much of a burden does this put on the FW/PX infrastructure? Firewalls (unlike proxies) typically work at the IP layer, not the TCP layer, so the scalability of the firewall is largely unaffected by the
specific usage of IP traffic. In other words, firewalls are mostly about the number of IP packets per second and don't particularly care whether those IP packets are shared by a small or large number of TCP connections because that IP-usage information is opaque to the firewall. Even when the TCP port number becomes relevant to the firewall for finer-grained access policies, the scalability of the firewall still comes down to the number of IP packets per second.

Proxies, whether they be SOCKS or HTTP proxies, are typically used to holding on to lots of concurrent TCP connections, across many different
end-users in the organization. By its very nature, SOCKS proxies must bridge individual TCP connections, while HTTP proxies support persistent connections created by the browser to send multiple HTTP requests over the same TCP connection. When HTTPS requests pass through
an HTTP proxy, they are SSL-encrypted so the proxy behaves as bytes-in, bytes-out with zero touch on the payload, making their behavioral and
scalability characteristics more closely resemble the SOCKS proxy. Kaazing WebSocket Gateway automatically uses an SSL-encrypted downstream when an intermediate HTTP proxy is detected.

Naturally, the precise capabilities of the FW/PX device will be vendor specific. However, Kaazing is more efficient on the wire for the same number of end users with the same requirements for frequency of update. If this concern does turn out to be a practical limitation of their hardware, then you can configure Kaazing WebSocket Gateway to use unencrypted long-polling through the proxy instead of encrypted streaming. This is done by removing the <accept>wss://...</accept> from the corresponding service entry in Kaazing WebSocket Gateway configuration, leaving the <accept>ws://...</accept> in place.

Licensing Questions

This section contains questions about licensing Kaazing WebSocket Gateway.

Where can I get the software and how do I get an evaluation copy of the enterprise edition?

The Community Edition of Kaazing WebSocket Gateway is available with no licensing fees from kaazing.com If you need to evaluate the full enterprise edition, please contact sales@kaazing.com for a trial license.

How much does Kaazing WebSocket Gateway cost?

Kaazing WebSocket Gateway is available under a conventional enterprise license and also as a cloud-service license. Please contact sales@kaazing.com for more information.

HTML5 Questions

This section contains questions about Kaazing and HTML5.

What is HTML5 and why does it matter?

HTML5 is the next set of W3C HTML standards. It offers new and enhanced features to address new HTML primitives, multimedia, offline use, communication, and so on. Many of the browser vendors have already implemented several of these features.

What is a WebSocket?

The HTML5 Communications specification describes a WebSocket as a full-duplex communications channel that operates over a single socket. WebSockets traverse firewalls and routers seamlessly and allow authorized cross-domain communication. A WebSocket connection is established by the client requesting an HTTP Upgrade during the initial negotiation, between the client and server. Once that handshake is successful, the connection is upgraded to bi-directionally stream 0xFF-separated UTF-8 messages.

Is the WebSockets specification included in HTML5?

Yes. WebSockets—like other pieces of the HTML5 effort such as Local Storage and Geolocation—was originally part of the HTML5 specification, but was moved to a separate standards document to keep the specification focused. WebSockets has been submitted to the Internet Engineering Task Force (IETF) by its creators, the Web Hypertext Application Technology Working Group (WHATWG). Authors, evangelists, and companies involved in the standardization still refer to the original set of features, including WebSockets, as "HTML5."

Is a WebSocket fast?

WebSocket is basically a thin abstraction over normal TCP sockets (plus source domain information for security purposes). They are just as fast as regular sockets.

What is Server-Sent Events?

Server-Sent Events (SSE) standardizes and formalizes how a continuous stream of data can be sent from a server to a browser. Server-sent events is designed to enhance native, cross-browser streaming. Server-sent events introduces eventsource, a new JavaScript API that connects to a server URL to receive an event stream.

Why should I care about Cross-Origin Resource Sharing and Inter-Document (iFrame) messaging?

W3C Cross-Origin Resource Sharing reduces the need for portals. Previously, portals were invented because of the single-origin security constraint of the Web; applications could only connect to servers that served up the application, for example, their origin. Web servers had to connect and aggregate information from a variety of Web sources in order to present them to the user on one Web page. This was primarily for security reasons (for example, to avoid cross-site attacks). HTML5 has addressed this issue. Aggregation can now occur on the browser without the need for portals and portal farms.

Inter-Document messaging allows Web developers to easily create Web application integration known as "mashups" on the browser. For example, one user can click on a particular company in a list of stocks in a portfolio application. The click could trigger a message to another document (iFrame) to retrieve and present the most up-to-date research report about that company.

I heard of Google Wave. How does that address real-time collaboration?

Google Wave is a set of open-source protocols and software APIs for real-time collaboration and instant communications. It is an exciting step towards real-time applications over the Web and towards Google's vision of using the Web as an operating system.

There are two protocols used in Google Wave: XMPP and JSON-RPC. Neither of these protocols specify a particular underlying network transport, especially over the Web. Typically XMPP is pushed to clients using a polling mechanism, which can cause issues with large numbers of users. For JSON-RPC, its recommended by json-rpc.org to use TCP/IP socket streams (and not HTTP) as the underlying transport.

It therefore makes sense to use WebSocket as the underlying network protocol for both XMPP and JSON-RPC in Google Wave. The streaming connection of WebSocket with its native TCP behavior seems a perfect fit to power Google Wave. An enterprise implementation of Google Wave using Kaazing WebSocket Gateway would provide large organizations with high-performance, zero-install real-time collaborative applications using standard Web technologies and products.

Where can I find a good tutorial on writing applications that use HTML5 Communications?

Kaazing WebSocket Gateway contains a set of tutorials and how-tos to get you started.

How do you compare Jabber, XMPP, RSS, and SMS to WebSocket?

XMPP (eXtensible Messaging and Presence Protocol) is a high-level XML-based IM protocol implemented by servers such as Jabber. RSS (Really Simple Syndication) is another popular XML-based protocol. Both of these protocols can be "pushed" over the Web using client-side or server-side polling. They can also be pushed using Kaazing's implementation of Server-Sent Events (or WebSocket for that matter). One of Kaazing WebSocket Gateway demos shows a simple Javascript-based Instant Messaging client communicating with Google Talk, an XMPP-based IM client. SMS, which typically is the protocol used for "texting" is a non-Web push technology used primarily on mobile phones. A WebSocket-to-SMS proxy would be very useful and straightforward to integrate with Kaazing WebSocket Gateway.

What is Stomp?

Streaming Text-Oriented Messaging Protocol (Stomp) is a simple protocol to connect to messaging systems. Stomp is a text-based interoperability protocol that allows messaging clients to connect to Stomp messaging servers. Due to its text-based nature, the Stomp protocol allows clients written in many different programming languages to connect to Stomp servers. Kaazing WebSocket Gateway comes with the Stomp-JMS adapter that allows Stomp clients to communicate with JMS message brokers.

More Questions?

If you have additional questions, don't hesitate to contact us.