Introduction

Overview

The AMQP Swiftlet is a high performance AMQP broker implementation which provides full support of the AMQP 1.0 specification, except the limitations noted below. It supports SASL authentication as well as SSL/TLS connections and fully integrates with JMS and all services of a SwiftMQ Universal Router and Federated Router Network.

Limitations

  • Durable subscriber links are identified by a terminus expiry policy of NEVER and a terminus durability of CONFIGURATION. All other links will be automatically overwritten with a terminus expiry policy of LINK_DETACH or SESSION_END (targets), no matter which expiry policy is set in the attach frame.
  • Link "detach(close=false)" is supported but the link will then be automatically closed on session close. Reattach of a Link (e.g. to change the properties of a Source or Target) is not supported. Instead "detach(close=true)" should be used followed by an attach with the new properties.

SwiftMQ AMQP 1.0 Client for Java

In addition to the AMQP broker implementation SwiftMQ provides an AMQP 1.0 Client for Java implementation which can be used to connect to any AMQP 1.0 broker (not only SwiftMQ) free of charge.

Support of AMQP Global Addressing (since 9.4.2)

Source and target addresses (queues or topics) can be in the AMQP Global Addressing format. SwiftMQ automatically extracts SwiftMQ destination names out of it.

For example, the following global addresses are all synonyms for "testqueue":

  • amqp://guest:guest@localhost:5672/testqueue
  • amqps://localhost:5672/testqueue
  • amqps://localhost:5672/testqueue@router1?a=b
  • amqp://localhost/testqueue
  • amqp:///testqueue
  • localhost:5672/testqueue
  • /testqueue
  • testqueue

JMS Integration

SwiftMQ is a JMS messaging system so all messages from/to AMQP clients are transformed to/from JMS messages on the fly by configurable transformer classes.

It is possible to define AMQP-only destinations with native transformer which stores the AMQP payload as BytesMessage body so there is no transformation overhead at all. To integrate with JMS and allow AMQP and JMS clients to produce and consume on the same destination a JMS mapping transformer can be defined which transforms an AMQP message into a typed JMS message and vice versa with all properties and header so there will be a full integration between AMQP and JMS clients, including mixed mode request/reply.

AMQP clients have full access to SwiftMQ resources and are not limited in any way. So they can create durable subscribers on topics, can access all kind of queues including creation of temporary queues, can use message selectors and so on. They are flow-controlled just like JMS clients.

SwiftMQ Universal Router Integration

The AMQP Swiftlet is fully integrated with the SwiftMQ Universal Router environment. Administration and monitoring takes place by SwiftMQ's well-known administration tools SwiftMQ Explorer, CLI, JMX and SNMP:

Exact accounting metrics such as message counts, size, users, date and time can be produced by using the AMQP source factory which is registered at the Accounting Swiftlet:

SASL interfaces directly with the Authentication Swiftlet of the SwiftMQ Universal Router which provides user, authentication and resource-limit group management.

Federated Router Network Integration

Since all messages are transformed into JMS messages, all features of the Federated Router Network are automatically available to AMQP clients. This allows AMQP-only as well as JMS-only and mixed AMQP/JMS operations router network wide:

SwiftMQ High Availability Router Integration

Transparent reconnect in the case of a failover between SwiftMQ HA instances is a feature of SwiftMQ's JMS client. AMQP is a protocol so transparent reconnect has to be done on top of it - inside AMQP client libraries. SwiftMQ's AMQP 1.0 Client does support non-transparent reconnect via link recovery.