The Kaazing WebSocket Gateway - AMQP Edition provides highly scalable, near zero-latency, full-duplex communication over the Web between an AMQP-compatible messaging system and a browser or mobile client. Developers can use the same AMQP APIs they already know, enabling rapid development and deployment of Rich Internet Applications that can be indistinguishable from desktop applications.
Be sure to check out the main Kaazing WebSocket Gateway product page for general information, whitepapers, and links to other Editions of Kaazing WebSocket Gateway.
|Key Features of the new Kaazing AMQP Edition 3.4 include:|
|Ability to close all inbound firewall ports for maximum security while still allowing web-based users access to data
For zero penetration into your trusted enterprise network, the AMQP 3.4 edition enables the ability to close all inbound firewall ports while still allowing Web users to connect
|Bandwidth control for more data services offerings and optimized bandwidth cost management
Offering volume-tiered data delivery services or to cap bandwidth utilization
Significantly lowered latency for better response time and decreased bandwidth to minimize data usage
|Features in the AMQP edition|
|AMQP Protocol End-to-End From Browser/Mobile Client over WebSocket to Server
Kaazing capitalizes on one of the most powerful aspects of WebSocket: that it can be used as a transport layer for higher-level protocols. Thus the client itself is communicating using the AMQP protocol, over the Web through firewalls and proxies.
Unlike traditional solutions, the client does not need to go through an intermediary application server with HTTP to be translated to the real protocol on the back-end. The client is effectively communicating to the AMQP broker directly.
|Works with AMQP 0-8, 0-9-0, 0-9-1
You can use any of these AMQP versions with Kaazing WebSocket Gateway.
Kaazing WebSocket Gateway multiplexes multiple channels on a single connection over the Web.
|Reliable Messaging with Acknowledgment
An acknowledgement is a formal signal from the client application to a message queue that it has successfully processed a message. You can use both the Automatic or Explicit models.
AMQP supports transactional messaging, through server local transactions. In a transaction the server only publishes a set of messages as one unit when the client commits the transaction. Transactions only apply to message publishing and not to the actual delivery of the messages or the consumption of the messages from a queue. Rolling back (canceling the transaction before it is committed) a transaction therefore does not remove any messages from a queue.
|Quality of Service
The quality of service controls how fast messages are sent. The quality of service depends on the type of content being distributed. In general the quality of service uses the concept of "pre-fetch" to specify how many messages or how many octets of data will be sent before the client acknowledges a message. The goal is to send message data in advance, to reduce latency.
|Message Flow Control / Client Throttling
Flow control is an emergency procedure used to halt the flow of messages from a peer. It works in the same way between client and server and is implemented by the Channel.Flow command. Flow control is the only mechanism that can stop an over-producing publisher.
|Exchanges Types: Direct, Fanout, Topic, Headers, and System
All of the AMQP exchange types can be used. Some of these exchange types (Direct, Fanout, and Topic) must be supported by all AMQP brokers while others (Headers and System) are optional. AMQP brokers can also support custom exchange types. The following are the different types of exchanges:
|Durable, Non-durable (Temporary), and Passive Exchanges
Exchanges can be durable, meaning that the exchange survives broker shut-down and must be deleted manually or non-durable (temporary) meaning that the exchange lasts only until the broker is shut down. To check if an exchange exists on the AMQP broker (without actually creating it), you can create a passive exchange.
|Queues: Durable, Exclusive, Passive, and Auto-Delete
To check if a queue exists on the AMQP broker (without creating it), you can create a passive queue. Additionally, queues can be marked exclusive, which means that they are tied to a specific connection. If a queue is marked exclusive, it is deleted when the connection on which it was created is closed.
Queues can be durable, meaning that the queue survives broker shut-down and must be deleted manually or non-durable (temporary) meaning that the queue lasts only until the broker is shut down. Queues can also be marked Auto Delete, which means that the queue is automatically deleted when it is no longer in use.
|Bind Exchanges to Queues
Once you have created an exchange and a queue in AMQP, you must bind, or map, one to the other so that messages published to a specific exchange are delivered to a particular queue.
|Send Binary Messages (Including Unicode Text)
The client can send and receive both binary and text messages.
|Mandatory and Immediate Message Options
Messages can be marked Mandatory to send a notification to the publisher in case a message cannot be delivered to a queue. You can also mark a message Immediate and the message is returned to the sender if it cannot be routed to a queue consumer immediately.
|Consume Options: No Local, No Ack, Exclusive
Publishers can choose to require acknowledgement (or not) of messages so that messages can be redelivered in the case of a delivery failure. If the queue is set to Exclusive, it is scoped to just the current connection and deleted when the connection on which it was established is closed. Additionally, you can use the No Local setting to notify the broker not to send messages to the connection on which the messages were published.
Ensure that clients must be authenticated before they can access your private data.
A virtual host is a data partition within the server, it is an administrative convenience which will prove useful to those wishing to provide AMQP as a service on a shared infrastructure.
|Core Features in all Kaazing WebSocket Gateway editions|
|FREE Developer License
You can develop, test, and evaluate as much as you want for free. When you download Kaazing WebSocket Gateway it comes with a 50-connection free developer license. Other than that it is fully functional with no restrictions or time-limited features.
|Based on W3C HTML5 and IETF Standards
Some of the HTML5 standards were designed to address the drawbacks of existing technology; HTML5 WebSocket is one such specification. Ajax and Comet are based on HTTP which was not designed for the requirements of modern-style browser applications.
HTML WebSocket is the next evolution in real-time communication over the Web, designed to be compatible with existing HTTP infrastructure, but without the limitations imposed by HTTP communication techniques.
|Full-duplex, Bi-directional Communication
The first thing most people notice about HTML5 WebSocket is that both the server and client can send data at any time, or even at the same time. This is in contrast to Ajax or Comet methods which rely on the client to regularly poll for data or perform other costly workarounds to simulate real-time communication.
|Minimal Bandwidth Consumption
Each message you send over a WebSocket has only two extra bytes to frame the beginning and end of the message. On the other hand, current HTTP communication such as Ajax or Comet include a large number of HTTP headers which are typically 1000 or more bytes. Therefore using HTML5 WebSocket can result in a drastic reduction in bandwidth, even on the order of 500x lower.
|Works With Any Browser
Any modern browser with native support for WebSocket can connect to the Gateway. But that's not all. Many environments can't or won't upgrade their browsers and Kaazing WebSocket Gateway makes sure they aren't left behind.
Kaazing's client emulation technology ensures older browsers can enjoy the benefits of Kaazing WebSocket Gateway with almost the same performance as native WebSocket. No plugins are required and browsers as old as Internet Explorer 6 are supported. Test it yourself by connecting to Kaazing.me with any browser.
Multiple levels of security for authentication, authorization, and encryption keep your data and your users safe — not just in the enterprise, but also over the Web. The HTML5 WebSocket specification has provisions for secure WebSocket connections. Kaazing WebSocket Gateway goes further offering a variety of authentication methods including the world's first implementation of Kerberos over WebSocket for secure authentication and authorization.
|Single Sign-On over the Web with Kerberos
Kaazing WebSocket Gateway supports SPNEGO-based Kerberos security, which you can integrate with your existing infrastructure to provide Single Sign-On capability. Kaazing is first in the world to offer SPNEGO-based Kerberos authentication using WebSocket over the Web.
|Mobile Browser Support
Modern browsers on mobile devices are also supported. For those without native WebSocket support, Kaazing's client emulation technology will let your applications run seamlessly.
|Suitable for the DMZ to Protect Trusted Systems
You want to be able share the data from your back-end systems and applications over the Web without exposing them to everyone on the Internet. Kaazing WebSocket Gateway is ideal to place in the DMZ to act as a front-line access point for those back-end systems which can reside safely in the trusted network.
|Cross Origin Connections
Allow cross-domain connections to your services and applications.
|Origin-based Access Control
Fine-grained access control to specify which domains can access your services and applications. For example, you can have public services or a whitelist to only allow specific origin domains.
|JMX Management and Monitoring
Manage and monitor Kaazing WebSocket Gateway connections and activity via JMX.
|Client SDKs for the AMQP edition|
|Flash / Flex / Air client: AMQP API
Get full end-to-end communication with the AMQP protocol, directly from the client to the broker. Developers have an API to perform AMQP operations in Adobe Flash, Flex, or Air. This allows you to connect standard Web applications to AMQP brokers transparently over WebSocket.
|Silverlight client: AMQP API
Get full end-to-end communication with the AMQP protocol, directly from the client to the broker. Developers have an API to perform AMQP operations in Silverlight. This allows you to connect standard Web applications to AMQP brokers transparently over WebSocket.
|.Net client: AMQP API
Get full end-to-end communication with the AMQP protocol, directly from the client to the broker. Developers have an API to perform AMQP operations from .Net. This allows you to connect standard Web applications to AMQP brokers transparently over WebSocket.
|Java client: AMQP API
Get full end-to-end communication with the AMQP protocol, directly from the client to the broker. Developers have an API to perform AMQP operations in Java. This allows you to connect standard Web applications to AMQP brokers transparently over WebSocket.