...

AMQP management is defined by the AMQP Management specification which is currently a Working Draft at Oasis.  It defines a standard way to identify objects within the Broker, to invoke operations (CRUD operations or arbitrary operations such as clearQueue) and pass arguments and get results, all over AMQP itself.  When interacting with management, you send management messages to a special address node ($management) .

For Broker-J:

which support a reply-to address.

It also defines a standard way to discover the objects that an device managed by AMQP exposes.  One idea here is that is should be possible to produce a generic console which is capable of managing (at least at a basic level) any device managed by AMQP.  

For Broker-J:

1. To manage a virtualhost
2. To manage a virtualhost, you connect with AMQP to the virtualhost as normal, then send management messages to $management.
3. To manage the Broker as a whole, you connect with AMQP to the virtualhost as normal, then send management messages to $management.
4. To manage the Broker as a whole, you connect with AMQP to a synthetic virtualhost $management and then send management messages a synthetic virtualhost $management and then send management messages to $management.

ManagementNode provides the implementation.

The model (objects, attributes, operations) are simple exposed simply exposed verbatim over AMQP Management.  In AMQP management, objects have a name identifying the type of the object.  This is defined using an annotation ManagedObject#amqpName.

HTTP management

HTTP, REST and Web Management

AMQP Management

Terms

The Broker's model is exposed as a REST API.  This allows simple tools such as cURL to be an effective way to both manage and monitor the Broker.

The URI for the REST API is /api/latest or /api/v<version>.  Currently the Broker supports only a single version of the API.  It is envisages that in future a mapping layer might maintain support for n older versions, thus allowing a smooth upgrade for those migrating to new Broker versions.

The URI is mapped to the object's within the tree.  The form of the URI is /api/latest/<category type>/<name1>/<name2>/.../<namen> where the names describe a path to an object starting at the root.  It is always possible to refer to objects by ids.

• POST/PUT - create or update
• DELETE - delete an object
• GET - get an object or a collection of objects.

The Broker embeds Jetty to provide the HTTP management interface.  HttpManagment configures Jetty according to the configuration provided to by the Port/KeyStore/TrustStore model objects.

The embedded server also provides a Web Management Console.  This is written using the Dojo framework.   It uses the REST API to interact with the Broker.