Kaazing and Kaazing WebSocket Gateway
Frequently Asked Questions
This document attempts to answer your frequently asked questions about Kaazing and Kaazing WebSocket Gateway. It contains the following sections:
- General Questions (WebSocket, Gateway features, business applications, etc)
- Developer's Questions (languages, protocols, code, data formats, etc)
- HTML5 Questions (standards, comparing protocols, etc)
- Administrator's Questions (security, networking, setup, etc)
- Licensing Questions (Open Source, Enterprise Edition, sales, etc)
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?
- Does Kaazing WebSocket Gateway support WebRTC?
- Does Kaazing WebSocket Gateway support mobile client notifications?
- 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 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?
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, AMQP). Kaazing WebSocket Gateway includes additional enterprise-ready server extensions such as enhanced security and protocol validation.
Most enterprises deploy several applications to their users. From a management perspective, keeping the network stack consistent across all the applications and all the programming technologies is a big win. Consistency reduces complexity and the associated 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.
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, SSO, Kerberos, and other security features. Also Kaazing WebSocket Gateway integrates with JAAS, supporting pluggable authentication modules. For more information, refer to the Security topics in the documentation for your Kaazing WebSocket Gateway.
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 in addition to WebSocket 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 might have real-time requirements to or from browsers in your Virtual Private Network (VPN). You might 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.
In scale and depth. 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!
Yes. For more information, see Deploy WebRTC using the Gateway.
Yes. For more information, see Configuring Mobile Client Notifications.
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:
- Microsoft .NET
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 MQ (MQSeries).
Yes. Java applications accessing cloud services over the Web is a common use case.
Yes. You can embed Kaazing WebSocket Gateway in a Java program as a server-side process. See Embed the Gateway in Your Java Application to learn how. For developers interested in an OEM relationship with Kaazing, please contact our sales office at email@example.com for more information.
Any browser that supports WebSocket, such as Safari, Chrome, Firefox, Opera, and most browsers that do not. Including Microsoft Internet Explorer 7.0+, 8.0+, 9.0+, 10.0+, and 11.0+. Mobile browser support includes Android 2.2 and greater, iOS 7.0 and greater, and Windows RT.
Kaazing offers binary support in its WebSocket libraries.
Kaazing WebSocket Gateway comes with documentation that includes tutorials complete with example code.
Kaazing is data format agnostic. Our client libraries 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|
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. All browser vendors have implemented several if not all 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 were originally part of the HTML5 specification, but were 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.
Kaazing WebSocket Gateway's documentation contains a set of tutorials and how-tos to get you started.
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).
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 Setting Up the Gateway and Clients. 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 Release Notes for Kaazing WebSocket Gateway.
These libraries are included with Kaazing WebSocket Gateway versions prior to 5.0.
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. To determine which service is using a port in Microsoft Windows, the easiest method is to use NETSTAT.EXE like this:
netstat.exe –a –n –o. In Linux/Mac, you can use
netstat -p TCP | grep 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.
For details on security, refer to the Security with Kaazing WebSocket Gateway topics in the documentation for Kaazing WebSocket Gateway.
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. There is also SSO (Single Sign-On), Kerberos, IP Filtering, Two-Factor Authentication, and Enterprise Shield™. Refer to the documentation 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.
Kaazing WebSocket Gateway uses Java 8, 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/SSL) by providing Secure WebSocket (wss). WS/WSS is similar to the HTTP-HTTPS relationship. By default, WebSockets use port 80 and Secure WebSockets use 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 service.
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 TLS/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 the Open Source Kaazing WebSocket Gateway Community Edition or the commercial Enterprise Edition from http://kaazing.org/download. All of the products there are available for evaluation, testing, and development.
Kaazing WebSocket Gateway is available under a conventional enterprise license and also as a cloud-service license. Please contact firstname.lastname@example.org or https://kaazing.com/contact/ for more information.