Kaazing and Kaazing WebSocket Gateway
Frequently Asked Questions
This document attempts to answer your frequently asked questions about Kaazing and Kaazing WebSocket Gateway, and it contains the following sections:
If you have additional questions after reading this FAQ, then please don't hesitate to contact us.
- What is Kaazing WebSocket Gateway?
- What are the primary features of Kaazing WebSocket Gateway?
- Is it necessary to use Kaazing if my Java application already tunnels through port 80?
- Can I continue to use Java Web Start to deploy Java applications?
- How secure is Kaazing WebSocket Gateway?
- Is Kaazing WebSocket Gateway a messaging system?
- Doesn't Comet already handle real-time communication over the Web?
- Does Kaazing use the Bayeux protocol?
- Don't chat protocols like XMPP and Jabber already handle real-time communication over the Web?
- How does Kaazing compare with the real-time updates I already get in Google Finance, Yahoo Finance, Twitter, and Facebook?
- Is Kaazing a Web "push" vendor? Didn't we see this movie before in 1999?
- Why use Kaazing when I already have a secure Virtual Private Network for my customers?
- How secure is cross-site scripting with Kaazing?
- As a cloud services provider, can I use Kaazing WebSocket Gateway to provide real-time services to my customers?
- How does Kaazing help me move towards HTML5 browser standards?
- How is Kaazing's WebSocket Gateway different from other servers that support WebSocket?
- What programming languages are supported by Kaazing WebSocket Gateway?
- Can native Java applications use Kaazing?
- Can C# applications use Kaazing?
- Can I embed Kaazing WebSocket Gateway in my Java program?
- Do you support JMS?
- Which browsers are compatible with Kaazing client libraries?
- How can I send compressed or encrypted binary data using WebSocket?
- Where can I see some example code?
- What data formats does Kaazing WebSocket Gateway support?
- What are the best practices to build applications that send structured data such as CSV, JSON and XML to and from browsers?
- How can I get Kaazing WebSocket Gateway to understand my TCP-based protocol so I can use it over the Web?
- How many sockets are opened between the browser and Kaazing WebSocket Gateway? And how many if cross-origin messaging is used?
- Which version of AMQP do you support?
- What happened to the Centurion, Dragonfire (and so on) releases?
- What are the hardware and software requirements for Kaazing WebSocket Gateway?
- How do I install Kaazing WebSocket Gateway?
- Do you require browser plug-ins?
- What is the impact on my networking infrastructure if I use Kaazing and do I need additional firewalls and proxies?
- Which version of Java is required to run Kaazing WebSocket Gateway?
- Where can I download the Adobe Flash/Flex libraries for Kaazing WebSocket Gateway?
- Kaazing WebSocket Gateway will not start when I try to run it. What am I doing wrong?
- Why can't I access Kaazing WebSocket Gateway at the default URL, http://localhost:8000
- Why do I receive "localhost is not found" when I try to access http://localhost:8000?
- How do I configure Kaazing WebSocket Gateway for optimal security?
- Can I integrate Kaazing WebSocket Gateway with an existing Web application server (for example, Apache)?
- What are the best practices to fully authenticate users and have a secure conversation using JMS?
- What can I do if my messaging server does not support Stomp?
- What level of encryption is supported by Kaazing WebSocket Gateway?
- What management tools are available with Kaazing WebSocket Gateway?
- Do you support Transport Layer Security?
- Do I need to open new ports on my firewall to enable Kaazing WebSocket Gateway?
- How do I architect my Kaazing WebSocket Gateway topology for global deployment?
- How do I setup Kaazing WebSocket Gateway for high-availability? Does Kaazing WebSocket Gateway work with load-balancing appliances?
- How do I use multiple Kaazing WebSocket Gateways to setup a remote publish/subscribe architecture?
- How would DNS find the endpoints on the "other" side of our Gateway in a forward and reverse gateway setup?
- How can the remote publish/subscribe use case work? Aren't JMS implementations incompatible?
- Is my network infrastructure taxed more heavily when I deploy Kaazing WebSocket Gateway as opposed to Comet and AJAX?
- What's the impact on the corporate firewall/proxy infrastructure when Kaazing WebSocket Gateway is employed?
- Where can I get the software and how do I get an evaluation copy of the enterprise edition?
- How much does Kaazing WebSocket Gateway cost?
- What is HTML5 and why does it matter?
- What is a WebSocket?
- Is the WebSockets specification included in HTML5?
- Is a WebSocket fast?
- What is Server-Sent Events?
- Why should I care about Cross-Origin Resource Sharing and Inter-Document (iFrame) messaging?
- How does Google Wave address real-time collaboration?
- Where can I find a good tutorial on writing applications that use HTML5 Communications?
- How do you compare Jabber, XMPP, RSS, and SMS to WebSocket?
- What is Stomp?
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.
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.
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).
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, and other security features. Also Kaazing WebSocket Gateway integrates with JAAS, supporting pluggable authentication modules. For more information, refer to the Security with Kaazing WebSocket Gateway topics in the documentation for your Kaazing WebSocket Gateway edition.
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.
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 bidirectional 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 bidirectional, real-time communication over the Web.
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.
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.
How does Kaazing compare with the real-time updates I already get in Google Finance, Yahoo Finance, Twitter, and Facebook?
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.
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 bidirectional 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.
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.
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.
As a cloud services provider, can I use Kaazing WebSocket Gateway to provide real-time services to my customers?
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.
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.
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!
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:
- 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).
Yes. Java applications accessing cloud services over the Web is a common use case.
Yes. Kaazing WebSocket Gateway supports Silverlight applications written in any .NET programming language such as C# and Visual Basic.
Yes. You can embed Kaazing WebSocket Gateway in a Java program as a server-side process. See Checklist: Embed Kaazing WebSocket Gateway in Your Java Application to learn how. For developers interested in an OEM relationship with Kaazing, please contact our sales office at firstname.lastname@example.org for more information.
For an overview of the certified browser versions for this release, refer to the Release Notes in the documentation for your edition.
Kaazing offers ByteSocket client library in addition to WebSocket. ByteSocket allows binary data to be sent over the Web.
Kaazing WebSocket Gateway comes with documentation that includes tutorials complete with example code.
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?
How can I get Kaazing WebSocket Gateway to understand my TCP-based protocol so I can use it over the Web?
The Kaazing documentation contains a tutorial about writing your own protocol client library.
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.
The Kaazing AMQP client libraries are compatible with AMQP version 0-9-1.
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|
For a list of the system requirements, refer to the Setting Up Kaazing WebSocket Gateway topic in the documentation for your edition.
For more information about the installation process, refer to Getting Started in the documentation for your edition. Installing and running Kaazing WebSocket Gateway is quick and easy. You can have it up-and-running in less that 10 minutes.
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.
For more information about system requirements, refer the README.txt for your edition.
These libraries are included with Kaazing WebSocket Gateway.
Make certain that the JAVA_HOME variable is set in your environment. Also, verify that you meet all the system requirements outlined in the Setting Up Kaazing WebSocket Gateway topic in the documentation for your edition.
The most common problem occurs when another Web server or process is already using the default port 8000. This is the default HTTP port to which Kaazing WebSocket Gateway attempts to bind at startup. To change this, perform the steps outlined in the Troubleshooting topics in the documentation for your edition.
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.
For details on security, refer to the Security with Kaazing WebSocket Gateway topics in the documentation for your Kaazing WebSocket Gateway edition.
Can I integrate Kaazing WebSocket Gateway with an existing Web application server (for example, Apache)?
Yes. This is described in detail in the documentation for your edition.
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 the Security with Kaazing WebSocket Gateway topics. Refer to the documentation for your edition for more information about how to configure security.
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.
Because 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 back-end messaging server.
Kaazing WebSocket Gateway provides the Stomp-JMS adapter. Refer to the documentation for your Kaazing WebSocket Gateway edition for more information on how to configure Stomp-JMS adapter integration.
Kaazing WebSocket Gateway uses Java 6, which supports providers for many of the most commonly used cryptographic algorithms.
Kaazing WebSocket Gateway leverages Java Management eXtensions (JMX) to monitor its behavior. Refer to the documentation for more information about monitoring.
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.
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.
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. For more information, see the documentation for your Kaazing WebSocket Gateway edition.
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.
How would DNS find the endpoints on the "other" side of our Gateway in a forward and reverse gateway setup?
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 bidirectional 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.
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.
You can download Kaazing WebSocket Gateway from http://kaazing.com/download.html. All of the products there are available for evaluation, testing, and development. They are fully functional for up to 50 connections, and have no feature restrictions or functionality that expires after a trial period.
Kaazing WebSocket Gateway is available under a conventional enterprise license and also as a cloud-service license. Please contact email@example.com for more information.
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.
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 bidirectionally stream 0xFF-separated UTF-8 messages.
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."
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.
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 "a mashup" 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.
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.
Kaazing WebSocket Gateway's documentation contains a set of tutorials and how-tos to get you started.
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.