Kaazing WebSocket Gateway |
|
Architectural Overview |
|
|
There is an ever-growing desire to provide bi-directional (full-duplex), real-time communication between the browser and the Web server, similar to that which enables desktop clients to interact with back-end systems. For example, the demand for real-time services on the Web is increasing at a torrid pace, requiring Web applications to display information such as live stock feeds or facilitate participation in games, bidding, chat, and so on. However, HTTP only supports half-duplex communication (requests and responses can flow only in one direction at a time), making it difficult to deliver real-time content.
Techniques such as Comet and Reverse Ajax were developed to allow server-initiated message delivery, a process in which information is pushed from the server to the client. However, these techniques have many limitations such as standardization, performance, and scalability. To address these issues, the HTML 5 specification defines Web sockets and server-sent events. The combination of these standards makes full-duplex, direct TCP communication a reality for the next generation of browsers.
Fortunately, Kaazing WebSocket Gateway makes full-duplex communication a reality today, even for the most antiquated browsers. Kaazing delivers an enterprise WebSocket server that is built for real-time business and enables bi-directional browser communication as proposed by the HTML 5 specification. Kaazing WebSocket Gateway integrates with a wide array of business services.
This document describes how Kaazing WebSocket Gateway works and contains the following sections:
History of the Real-Time Web
Polling, a technique in which the client (browser) sends HTTP requests at regular intervals and immediately receives a response, represents the initial attempt to deliver real-time information on the Web. However, the downside of polling is that it generates a lot of unnecessary requests, which can impact both client and server performance. For example, if a request is sent by the browser every second and the server only sends messages at a 17-second interval, then there are 16 unnecessary requests taking up server resources and network bandwidth. Obviously, there is a simple solution to this problem if the interval of message delivery is known. The solution is to synchronize the interval at which a request is made by the client with that at which a message is ready for delivery on the server. However, real-time data is often not that predictable, making unnecessary requests inevitable.
Current attempts to solve the problem now largely center around server-side push technology, the most notable of which is Comet or Reverse Ajax. Comet introduces a way to delay the completion of an HTTP response to deliver messages to the client, a technique often called a hanging-GET or pending-POST. Comet-based push is generally implemented in JavaScript and uses connection strategies such as long-polling or streaming.
Long-Polling and Streaming
In the case of long-polling, also known as asynchronous-polling, the browser sends a request to the server and the server keeps the request open for a set period. If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request. In a case where a large number of messages must be sent, long-polling does not provide any substantial performance improvements over traditional polling. This lack of performance can be attributed to the number of HTTP headers, present in both long-polling and polling, which often accounts for more than half of the network traffic. Additionally, if secure connections--connections using Transport Layer Security (TLS)--are used in combination with long-polling, the setup and tear down of each connection is costly, unless the client establishes an HTTP 1.1 persistent connection.
When streaming is used, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated. A request is sent and kept open indefinitely (or for a set period of time) and the response is updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages. One benefit of streaming is reduced network traffic, which is the result of sending packets that only contain data rather than packets that contain both data and HTTP headers. The downside of streaming is that it is still encapsulated in HTTP, so intervening HTTP proxies may choose to buffer the response, increasing the latency of the message delivery.
Traditional Java EE Architecture with Streaming Support
By way of example, let's look at a fairly common scenario in which the requirement is to stream data from a back-end data feed (for example, a feed that contains stock information) to a client browser. Using traditional application design, the browser connects to an application server and application-specific bridge code in the application layer handles the translation between the APIs and the browser. This can be implemented as a custom Servlet, which internally uses a Java Message Service (JMS) client. The custom Servlet interprets custom JavaScript application protocols and maps these to standard APIs. Comet or reverse Ajax techniques might be used to push data to the clients. The following figure shows a traditional Java EE architecture used to extend various protocols (including JMS) to the browser.
Since the Java EE Servlet uses HTTP to talk to the browser, a full-duplex communication all the way between the server and the browser is never achieved; The Java EE Container has, in this case, become the throughput bottleneck. There are additional issues with this implementation. Many protocols, including those used by Java EE, are based on TCP and therefore have specific message-delivery guarantees. It is now up to the application developer to ensure that the same guarantees are enforced all the way to the browser and back.
Additionally, there may be a requirement to manually implement long-polling or streaming to push data to Web clients. Furthermore, developers must design an application protocol between browser and server, implementing their own JavaScript and Web Servlet listener that understands a custom protocol, and map the JavaScript calls into standard API calls. Finally, the JMS Client may not originally be designed to scale to a large number of clients, but may be forced to, causing competition for CPU resources on the Web application host between dealing with many concurrent synchronous requests and processing the Web application logic.
HTML 5
The HTML 5 specification and, more specifically, its Communication section defines Web sockets and server-sent events, which makes full-duplex, direct TCP communication a reality for browsers. This section of the HTML 5 specification is drawing a lot of attention. The first public draft of the HTML 5 specification was published by the World Wide Web Consortium (W3C) in January 2008, and browser vendors are already targeting certain features in the specification.
The idea of putting a full-duplex channel into the specification is not new; the TCPConnection API and protocol were initially drafted over two years ago. With recent development, in which Kaazing Corporation played a contributing role, the HTML 5 Communication section has been solidified and is now nearly complete with few, or no, additions planned. This makes it easy for browser vendors to implement native support for the Communication section of the specification, despite the full HTML 5 proposal remaining in draft form.
Three significant areas in the HTML 5 specification that impact cross-site, real-time Web development are:
Cross-Document Messaging
To prevent cross-site scripting attacks, browsers enforce a same-origin policy, which prevents documents with different origins from affecting each other. Unfortunately, this security feature also blocks non-malicious communication between pages on different origins. Cross-Document Messaging provides a system that allows documents to securely communicate across different origins.
The postMessage function, as defined in HTML 5, allows you to communicate between documents served by different origins. You call postMessage on the target document’s window, passing the message and the expected origin of the destination, as shown in the following example.
document.getElementsByTagName('iframe')[0].contentWindow.postMessage
('KZNG', 'http://stock.example.com');
In this example, the message KZNG is sent to the document of the first iframe element, expecting the target origin to be http://stock.example.com. The receiving iframe, served by http://stock.example.com, has to add an event listener to handle the incoming events, as shown in the following example.
function onmessage(event) {
if (event.origin == 'http://www.example.com') {
if (event.data == 'KZNG') {
event.source.postMessage('KZNG:1.01', event.origin);
}
}
}
window.addEventListener('message', onmessage, false);
Server-Sent Events
Server-sent events 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 as shown in the following example.
var eventSource = new EventSource("http://stocks.kaazing.com");
eventSource.onmessage = function(event) { alert(event.data); };
A connection to the server stocks.kaazing.com is established and when this server sends an event stream, a message event dispatched to the onmessage handler. For example, if the server sends the following event (where \n represents a newline character):
event: message\n
data: {'KZNG': 1.01}\n
\n
Then the EventSource implementation in the browser dispatches {'KZNG': 1.01}. In this case, the stock price for KZNG is received by the client and displayed on the page.
Additionally, if the server includes the id header for an event, then the client adds a Last-Event-ID header when it reconnects, so that the event stream can resume without repeating or missing any events when the HTTP response completes, thus guaranteeing message delivery. The HTTP response can complete normally or else abruptly, if the underlying TCP connection is broken due to some network error. Furthermore, the server can control how long the client must wait before reconnecting by specifying an optional retry header as part of an event in the event stream.
Web Sockets
The HTML 5 Web sockets specification introduces the WebSocket interface, which defines a full-duplex communications channel that operates over a single socket. WebSocket:
- Traverses firewalls and routers seamlessly
- Allows authorized cross-domain communication
- Integrates with cookie-based authentication
- Integrates with existing HTTP load balancers
A WebSocket connection is established by upgrading from the HTTP protocol to the WebSocket protocol during the initial handshake between the client and the server. Once established, WebSocket data frames can be sent back and forth between the client and the server in full-duplex mode.
Although the WebSocket protocol is ready to support a diverse set of clients, WebSocket cannot deliver raw binary data to JavaScript, because JavaScript does not support a byte type. Therefore, binary data is ignored if the client is Javascript.
WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, support for SSL is inherent. Server-sent events and Web sockets are not natively supported by modern browsers. Kaazing WebSocket Gateway to the rescue!
Kaazing WebSocket Gateway
Kaazing WebSocket Gateway is a cutting-edge, enterprise WebSocket server that enables full-duplex communication from the browser to any TCP-based back-end service (for example, JMS, JMX, IMAP, and Jabber). Kaazing WebSocket Gateway eliminates the need for complex server- and client-side architectures to bridge various protocols to the browser over HTTP.
This simplified architecture allows developers to code directly against back-end services, using JavaScript or other technologies such as Adobe Flex, Microsoft Silverlight, and Java, and this eliminates the need for complex server- and client-side architectures to bridge various protocols to the browser over HTTP.
Developers simply configure Kaazing WebSocket Gateway to communicate directly with the back-end APIs (for example, Stomp or XMPP), and develop their client application, allowing them to maintain focus on what matters most: building applications, instead of reinventing the wheel.
Kaazing WebSocket Gateway Components
Kaazing WebSocket Gateway consists of the following components:
- Server—An enterprise WebSocket server that enables direct TCP connectivity between browsers and back-end services
- Client Libraries—A set of protocol-specific client libraries
- Extensions—A set of enterprise-ready extensions for Kaazing WebSocket Gateway
Kaazing WebSocket Gateway Architecture
To fully appreciate the benefits of the Kaazing WebSocket Gateway architecture, it is useful to compare it to current real-time Web application architectures. Kaazing WebSocket Gateway can dramatically simplify and increase the performance of a similar solution.
HTML 5 Server-Sent Events Architecture
Kaazing WebSocket Gateway supports broadcast notification of data sent from a backend service to all connected clients. The backend data source typically sends data to Kaazing WebSocket Gateway over User Datagram Protocol (UDP) and browsers can then receive new notifications using server-sent events. The following figure shows a news feed that broadcasts custom UDP messages to Kaazing Gateway, which, in turn, fans the packet data out to all connected browser clients using server-sent events.
Enterprise HTML 5 Server-Sent Events Architecture
Setting up Kaazing WebSocket Gateway in an enterprise topology is not much different from a standard setup. The Kaazing Gateway can be configured for high availability and failover. To reduce complexity and provide increased scalability in server-sent events scenarios, Kaazing Enterprise Gateway supports multicast. This means that a back-end data source can be configured to send packets once to a multicast IP address (an IP address with the multicast address mask of 224.0.0.0). Therefore, the data source does not have to be aware of all its clients and, unlike the UDP broadcast scenario shown in the previous example, the data source only needs to send each packet once to every Kaazing Gateway in a high-availability cluster.
The following figure shows a news feed that uses multicast to send messages. Multiple Kaazing Gateways, front-ended by a reverse proxy server or load balancing router, are configured to listen for data on the multicast address and fan the packet data out to all connected browser clients using server-sent events.
HTML 5 WebSocket Architecture
Kaazing WebSocket Gateway is configured to interpret emulated or native TCP calls and pass them directly to any TCP-based back-end service (for example, a JMS broker, a database, an IMAP server, or an instant messaging server). An end-to-end TCP connection is established, as shown in the following figure, over which messages are sent with minimal overhead.
As illustrated, the browser connects directly to Kaazing Gateway. The client libraries, loaded in the client browser, direct requests to Kaazing Gateway. Kaazing Gateway supports the WebSocket protocol and can also emulate the WebSocket protocol using two HTTP connections—one for upstream communication and one for downstream communication. The downstream connection is implemented using the server-sent events wire protocol, so that native browser server-sent events and WebSocket implementations work immediately when they become available.
Enterprise HTML 5 WebSocket Architecture
Setting up Kaazing WebSocket Gateway in an enterprise topology is not much different from a standard setup. Kaazing Enterprise Gateway TCP connections seamlessly traverse firewalls and proxy servers between the different enterprise tiers, ensuring that message delivery guarantees are maintained. Additional hardware load-balancing routers and additional Kaazing Gateways can be configured for high availability and failover.
The following figure shows an example topology with multiple Kaazing Gateways, front-ended by a reverse proxy server, configured to send real-time data to the browser clients. You can also integrate Kaazing Gateway with other Web servers.
Kaazing WebSocket Gateway Features
The following are the key features of Kaazing WebSocket Gateway:
- Reliability—Message delivery from back-end systems and services is guaranteed all the way from the server to the browser and vice versa in the same way that the HTML 5 Specification guarantees TCP message delivery natively.
- Standards-Compliance—The current implementation of Kaazing WebSocket Gateway is based on the HTML 5 standard. Once browsers support full-duplex connectivity, per the HTML 5 specification, there is no requirement to change any server or client code; applications automatically take advantage of the native implementations of HTML 5's server-sent events and Web sockets with improved performance.
- Binary and Text-Based Protocol Support—While the Web Sockets specification only supports text-based protocols, Kaazing WebSocket Gateway also supports binary protocols, enabling raw TCP communication between client and server.
- Scalability—Kaazing WebSocket Gateway is stateless and therefore scales quite easily to enormous amounts of concurrent users. Kaazing Gateway runs separately from application logic hosted in an application server, which mitigates competition for resources.
- Performance—HTTP is a request and response-driven protocol, whereas TCP is centered around the reliable delivery of message data. Header information is sent with each HTTP request and response, which is an unnecessary overhead, and virtually eliminated by Kaazing Gateway, which favors TCP traffic.
- Client Optimization—Kaazing WebSocket Gateway detects the presence of the browser's Flash plugin. If the plugin is installed, client libraries can take advantage of a single TCP socket connection with Kaazing Gateway. If a direct connection is not possible (for example, if communication must flow through a firewall via an HTTP Proxy), then the client libraries can still take advantage of the Flash runtime, minimizing the client's memory profile.
- Client-Side APIs—Kaazing WebSocket Gateway provides a set of protocol-specific client libraries for different client technologies.
- Low Latency—There is no longer a need for the browser to contact server systems through custom Servlets or complex application server logic; the browser can now send binary data packages and receive an immediate response.
- Protocol Validation—Kaazing WebSocket Gateway has built-in protocol awareness, allowing it to verify that bytes passing through Kaazing Gateway match the expected protocol wire format. This check helps to prevent buffer overrun attacks or other malicious attacks on the back-end server.
- Cross-Browser Certification—Kaazing WebSocket Gateway is certified on all major browsers. Refer to Release Notes for information about the browser versions that are certified in this release.
- Resilient Messaging—Network proxy servers and firewalls are no longer a problem. In case of a broken request, Kaazing Gateway automatically reconnects, guaranteeing message delivery. Since all connectivity, including downstream server-sent events requests, is client-initiated, Kaazing WebSocket Gateway can seamlessly traverse firewalls and proxy servers. Additionally, Kaazing's emulation layer automatically honors the browser's proxy settings, eliminating any potential problems with connections that must pass through a Web proxy server.
- Security—Kaazing WebSocket Gateway supports wire encryption using HTTPS, W3C Cross-Origin Resource Sharing, and HTTP-based authentication and authorization. Furthermore, Kaazing WebSocket Gateway integrates with JAAS, supporting pluggable authentication modules. See also: Kaazing Security Overview.
- Password Keyring—Client libraries provide encrypted storage to remember the credentials for the backend systems to expedite application startup. Encrypted credentials sent to Kaazing Gateway are automatically injected into the protocol before authenticating with the backend system.
- Management—Kaazing WebSocket Gateway exposes a set of MBeans that allow administrators to manage and monitor the internal state of Kaazing Gateway.
- Storage—Client libraries provides browser session storage and local storage as defined in the Storage section of the HTML 5 specification.
- Proxy Streaming--Proxy servers typically buffer unencrypted HTTP responses introducing unpredictable latency during HTTP response streaming. Kaazing Gateway automatically redirects to use encrypted HTTP traffic to enable HTTP response streaming for server-sent events and WebSocket connections when an HTTP proxy is detected. If Kaazing Gateway has not been configured to support HTTP encryption then long-polling is used as a last resort to guarantee functional correctness.
- JMS support—The Kaazing Stomp-JMS Adapter enables Stomp client applications to communicate directly with any JMS-compliant messaging broker.
- Broadcast Notification—Kaazing WebSocket Gateway supports broadcast notification of data sent from a backend service to all connected clients. The backend data source typically sends data to Kaazing WebSocket Gateway over UDP and browsers can then receive new notifications using server-sent events.
- Multicast Support—Kaazing Gateway supports multicast so that a data source can be configured to send packets once to a multicast IP address (an IP address with the multicast address mask of 224.0.0.0). Multiple Kaazing Gateways can be configured to receive the same multicast data. This approach reduces complexity and provides increased scalability, because the data source does not have to be aware of all its clients and does not have to send each packet once to every Kaazing Gateway in a high-availability cluster.
Understanding the Kaazing WebSocket Gateway Components
The following is a detailed description of the various Kaazing Enterprise Gateway components:
Server
Kaazing Gateway's server component is an enterprise WebSocket server that enables full-duplex TCP connectivity between browsers and back-end services. In case native support for WebSocket is not available in the browser, the socket connectivity between browsers and Kaazing Gateway is emulated using two HTTP connections. The server component proxies communication to the remote server over raw TCP.
Kaazing Gateway is based on Staged Event-Driven Architecture (SEDA), and it leverages Java New I/O (NIO) for enhanced Java networking functionality. For example, instead of assigning a single thread per request, the server shares threads for optimal performance.
The server can serve static HTML content. It can also be used in conjunction with a Web application server. However, if a Web application server is used to serve HTML resources, then Kaazing Gateway must reside on a subdomain of the application server.
Client Libraries
The following protocol-specific client libraries are available:
- PostMessage Client Library
- XMLHttpRequest Client Library
- ServerSentEvents Client Library
- WebSocket Client Library
- ByteSocket Client Library
- StompClient Client Library
- XmppClient Client Library
- IrcClient Client Library
- DarkstarClient Client Library
PostMessage Client Library
The PostMessage client library allows HTML 5 cross-document messaging, such as between a main document and an embedded iframe. The W3C designed HTML 5 cross-document messaging so that both main documents and embedded iframes can communicate securely when they originate from different sources when they agree to do so. If the browser does not support PostMessage natively, the library automatically falls back to emulated mode--a feature that allows any modern browser to enjoy the benefits of HTML 5 cross-document messaging.
XMLHttpRequest Client Library
The XMLHttpRequest client library allows you to make cross-origin XMLHttpRequests, leveraging the W3C Cross-Origin Resource Sharing specification. Without this support, XMLHttpRequests cannot be made outside of a document's origin domain. Using the XMLHttpRequest client library, you can make cross-origin XMLHttpRequests requests as long as both the browser and remote destination implement the specification and if the remote destination accepts requests from the origin domain. If the browser does not support cross-origin XMLHttpRequest natively, the library automatically falls back to emulated mode--a feature that allows any modern browser to enjoy the benefits of cross-origin XMLHttpRequests.
ServerSentEvents Client Library
The ServerSentEvents client library allows clients to connect to any standards-compliant server-sent events stream. Server-sent events standardizes and formalizes how a continuous stream of data can be sent from a server to a browser. If the browser does not support server-sent events natively, the library automatically falls back to emulated mode--a feature that allows any modern browser to benefit from the server-sent events standard.
WebSocket Client Library
The WebSocket client library can be used to open a bi-directional connection to communicate directly with a back-end service using text-based protocols (Jabber, IMAP, and so on). Once established, the connection remains open and both the client and the server can send information back and forth asynchronously. In case the browser does not support WebSocket natively, the library automatically falls back to emulated mode--a feature that allows any modern browser to benefit from the WebSocket standard.
ByteSocket Client Library
The ByteSocket client library uses the same APIs as WebSocket and can be used to open a bi-directional connection that communicates directly to a back-end service using binary communication.
StompClient Client library
Implemented using the ByteSocket client library, the StompClient client library allows developers to send and receive Streaming Text Orientated Messaging Protocol (Stomp) messages to and from a Stomp-compliant server such as Apache ActiveMQ or RabbitMQ with the rabbitmq-stomp adapter. The StompClient client library allows developers to take advantage of many JMS features, like queuing, broadcasting, and publish and subscribe (pub/sub) in the same way that these JMS APIs can be used in Java, using the Stomp-compliant server's JMS client library.
XmppClient Client library
Implemented using the WebSocket client library, the XmppClient client library allows developers to send and receive messages to and from an XMPP server and to take advantage of many XMPP features. XMPP is popular chat protocol used, for example, by Google Talk. To support group chat, the XmppClient client library exposes the XmppRoom API. Because the implementation is layered on top of the WebSocket, and ServerSentEvents client libraries, Kaazing WebSocket Gateway provides accurate buddy lists by extending presence awareness all the way to the browser.
IrcClient Client library
Implemented using the ByteSocket client library, the IrcClient client library allows developers to send and receive messages to and from an Internet Relay Chat (IRC) server and to take advantage of many IRC features. IRC is a popular group chat system. The IrcClient client library uses Kaazing's ByteSocket client library, because IRC supports binary communication.
DarkstarClient Client library
Implemented using the ByteSocket client library, the DarkstarClient client library allows developers to send and receive messages to and from a Project Darkstar Server (PDS) and to take advantage of the Project Darkstar features. Project Darkstar is an open-source gaming software infrastructure project. The DarkstarClient client library uses Kaazing's ByteSocket client library, because Project Darkstar protocol sends only binary data.
Extensions
Kaazing Enterprise Gateway features the following extensions:
-
Protocol Validation—A service that verifies that bytes passing through Kaazing Gateway on their way to the back-end server match the expected protocol wire format, which helps to prevent buffer overrun and other malicious attacks on the back-end server.
-
Protocol Encryption—By intercepting communication with the backend server, Kaazing Gateway can satisfy the need for dynamic wire encryption in various protocols without requiring the browser to implement wire encryption in JavaScript. Instead, a secure WebSocket can be exposed by Kaazing WebSocket Gateway to leverage the browser's native wire encryption support. This feature allows the XmppClient client library to securely communicate with backend XMPP servers, such as Google Talk, that require dynamic wire encryption after the initial handshake.
-
Keyring Service—client libraries provide encrypted storage to remember the credentials for the backend systems to expedite application startup. Encrypted credentials sent to Kaazing Gateway are automatically injected into the protocol before authenticating with the backend system.
- Stomp-JMS Adapter—A service that enables Stomp client applications to communicate directly with any JMS-compliant messaging broker.
Summary
Until now, achieving bi-directional browser communication, which is vital for real-time Web applications, has been an elusive goal only partially achieved with an assortment of hacks. Techniques such as Comet and Reverse Ajax were developed to allow server-initiated message delivery, but these techniques have many limitations.
Recent updates to the HTML 5 specification, and specifically the definitions of Web sockets and server-sent events have changed the landscape. Developers can now take advantage of a full-duplex communication channel that operates over a single socket, as soon as browser vendors implement native support for this standard.
Kaazing WebSocket Gateway is an HTML 5-compliant WebSocket server that makes full-duplex binary and text communication a reality today, for all major browsers. It enables browsers to open a socket connection to any TCP-based back-end service (for example, JMS, JMX, IMAP and Jabber). Therefore, it is now possible to simplify the convoluted Java EE architectures of the past and build applications that directly communicate with back-end services using native protocols over HTTP.
Thus, with the help of Kaazing WebSocket Gateway and Web sockets, the browser now becomes a first-class citizen of network communications; a benefit that has long been enjoyed only by desktop applications. As a result, Kaazing WebSocket Gateway brings the promise of migrating the desktop to the Web.
If no native support is available in the browser, Kaazing WebSocket Gateway falls back to the client-side emulation of the standard automatically. Once browsers support full-duplex connectivity, per the HTML 5 specification, there is no requirement to change any server or client code; applications automatically take advantage of the native implementations of HTML 5 with optimal performance.
Therefore, Kaazing WebSocket Gateway delivers the future of Web application development today, and ensures that your applications are future-proof for the Web of tomorrow. Kaazing WebSocket Gateway is built for real-time business.