Chapter 3. Red Hat JBoss A-MQ Features
Abstract
Red Hat AMQ extends the basic JMS feature set to enable developers to build messaging applications that are flexible, highly available, reliable, scalable, highly performant, and easily administered.
3.1. Flexibility
Overview
Red Hat AMQ provides a variety of ways for building and deploying messaging applications including:
- support for a variety of transport protocols
- APIs for non-Java clients
- deployment and container options
- specialized destination types
Connectivity options
AMQ provides a variety network protocols that enable producers and consumers to communicate with a broker:
- OpenWire—The default wire protocol used to serialize data for transmission over the network connection. It uses a binary encoding format. OpenWire supports native JMS client applications and provides client libraries for C, C++, and .NET.
- Extensive Messaging and Presence Protocol (XMPP)—Enables instant messaging clients to communicate with the broker.
- Hypertext Transfer Protocol/Hypertext Transfer Protocol over SSL (HTTP/S)—Favored protocol for dealing with a firewall inserted between the broker and its clients.
- IP multicast—Provides one-to-many communications over an IP network. It enables brokers to discover other brokers in setting up a network of brokers, and clients to discover and establish connections with brokers.
- New I/O API (NIO)—Provides better scalability than TCP for client connections to the broker.
- Secure Sockets Layer (SSL)—Provides secure communications between clients and the broker.
- Streaming Text Oriented Messaging Protocol (STOMP)—A platform-neutral protocol that supports clients written in scripting languages (Perl, PHP, Python, and Ruby) in addition to clients written in Java, .NET, C, and C++.
- Transmission Control Protocol (TCP)—For most use cases, this is the default network protocol.
- User Datagram Protocol (UDP)—Also deals with a firewall inserted between the broker and its clients. However, UDP guarantees neither packet delivery nor packet order.
- Virtual Machine (VM)—Provides connection between an embedded broker and its clients.
For details, see the Client Connectivity Guide on the Red Hat Customer Portal.
Client-side APIs
AMQ provides client-side APIs for variety of programming languages. The language support varies based on the transport connection used by the client.
When using OpenWire you can use the following client APIs:
- C
- C++
- .NET
When using STOMP you can use the following client APIs:
- Perl
- PHP
- Python
- Ruby
Container options
In addition to being deployed as a standalone Java application, AMQ can be embedded in other Java applications. Embedded brokers can run client and broker functions concurrently in one process. Clients that run in the same processes as an embedded broker can use the VM transport to improve communication speed with the broker. Embedded brokers can still connect to external clients.
Red Hat AMQ can be deployed in a number of JEE and OSGi containers including:
- Red Hat JBoss Fuse
- Apache Tomcat
- Apache Geronimo
- Jetty
- JBoss
- WebSphere
Composite destinations
Composite destinations provide a mechanism for producers to send the same message to multiple destinations at the same time.
For an enterprise that needs real-time analytics, this feature enables its messaging application to send one message concurrently to many different client applications to process. For example, only one producer need send a single message to the warehouse to request more inventory and, at the same time, to broadcast that message to an in-store monitoring system that tracks customer purchases, current stock levels, and inventory replacement.
A composite destination treats a string of multiple, comma-separated destinations as one destination, but sends messages to each of the individual destinations. Composite destinations must be made up of comma separated lists that that are made up of either all topics or all queues.
For details, see the Client Connectivity Guide on the Red Hat Customer Portal
Virtual destinations
Virtual destinations provide a mechanism for publishers to broadcast messages via a topic to a pool of receivers subscribing through queues.
To do so, consumers register a subscription to a queue that is backed by a virtual topic, like this:
Consumer.<qname>.VirtualTopic.<tname>.
When the producer publishes messages to the virtual topic, the broker pushes the messages out to each consumer's queue, from which the consumers retrieve them. This feature enables you to failover queue subscribers, to load balance messages across competing queue subscribers, and to use message groups on queue subscribers.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).
