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

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

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.

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.

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.

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.

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.

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:

• Direct — Messages are sent only to a queue that is bound with a binding key that matches the message's routing key.
• Fanout — Messages are sent to every queue that is bound to the exchange.
• Topic — Messages are sent to a queue based on categorical binding keys and wildcards.
• Headers — Messages are sent to a queue based on their header property values.
• System — Messages are sent to system services.

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.

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.

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.

The client can send and receive both binary and text messages.

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.

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.

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.

Go to the download page

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.

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.

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.

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.

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.

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.

Allow cross-domain connections to your services and applications.

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.

Manage and monitor Kaazing WebSocket Gateway connections and activity via JMX.

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 JavaScript. This allows you to connect standard Web applications to AMQP brokers transparently over WebSocket.

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.

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.

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.

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.