# Object creation and deletion via management
## Status
Draft
## Summary
A protocol independent scheme for creating and deleting broker objects
via correctly formatted management messages. [See also QPID-3015]
## Problem
At present queues and exchanges cannot be created via QMFv2. Having a
means to do so would allow for more unified broker management. It
would also allow applications that have a need to do this sort of
broker manipulation to utilise a protocol independent, message-driven
approach (as used in QMFv2 method invocation for example).
## Solution
Define create() and delete() methods in the broker class in the
management schema
<method name="create" desc="Create an object of the specified type">
<arg name="type" dir="I" type="sstr"
desc="The type of object to create"/>
<arg name="name" dir="I" type="sstr"
desc="The name of the object to create"/>
<arg name="properties" dir="I" type="map"
desc="Type specific object properties"/>
<arg name="lenient" dir="I" type="bool"
desc="If specified, ignore unrecognised object properties as
long as type is recognised"/>
</method>
<method name="delete" desc="Delete an object of the specified type">
<arg name="type" dir="I" type="sstr"
desc="The type of object to delete"/>
<arg name="name" dir="I" type="sstr"
desc="The name of the object to delete"/>
<arg name="options" dir="I" type="map"
desc="Type specific object options for deletion"/>
</method>
These would then be invoked like any other QMFv2 method. The types of
object supported and the various properties these recognise will be
documented.
I propose initially to support creation and deletion of three basic
object types through this mechanism: queue, exchange and
binding. Exchanges will have 'topic' as a type alias and will also
recognise a sub-type property, corresponding to the AMQP 0-10 exchange
type. The default will be topic exchanges. This matches the current
usage in the addressing syntax for the messaging API.
## Rationale
There are alternative approaches to message based creation and
deletion that could be taken. For example:
(1) Augment the QMFv2 protocol definition with opcodes for creation
and deletion requests rather than using schema specific methods.
(2) Define a mechanism for message based creation or deletion of
objects that is entirely independent of QMFv2.
The different approaches really only involve slightly different
formats to the map messages sent and received, and perhaps the exact
address to which they are sent. The basic mechanism would remain the
same.
However, I do not want to commit to altering the design of QMFv2 whose
scope is broader than the basic broker management which qpidd
requires. Neither do I want, at this stage at least, to replace QMFv2
entirely. I chose the solution above as, for now, it seems like the
most consistent option within the scope of Qpid 0.10.
Likewise there are alternative ontologies for the objects thus created
(or deleted). While 'queue' is probably obvious and uncontroversial,
exposing exchanges and bindings are possibly less so. The rationale
here is to find a simple solution that adequately (and intuitively)
supports the AMQP 0-8 to 0-10 model for those familiar with it (which
is after all the only model currently supported), while alluding to a
transition to one where the pub-sub topic concept is more completely
and explicitly supported.
The set of types will be easily extensible (e.g. could even be extended
to cover the links and bridges used in the current inter-broker routing
solution).
Likewise in the future we can deprecate certain type- and/or property-
names.
## Implementation Notes
1. add above method definitions to management schema (add in some
documentation on types and properties here and/or elsewhere)
2. modify brokers to handle the new methods by creating the
appropriate queues, exchanges or bindings
3. create some tests and examples
## Consequences
Development:
This should not affect the way developers work on Qpid. The code level
changes are small and very localised.
Release:
This will not affect the release infrastructure or process.
Documentation:
We need to document the new methods, the types and properties
supported and ideal provide descriptions and examples of direct use of
QMFv2 from within a messaging application.
Configuration:
The change covers a new alternative for configuring the broker. You can
now write a trivial messaging program in a protocol independent API
that configures the broker. You need not rely on qpid-config or the
old AMQP 0-10 specific APIs for this or complicate the applications
themselves through dynamic construction squeezed into addressing.
Compatibility:
It does not break API (and there is no broker ABI as yet). It extends
the supported schema we expose however.
## Contributor-in-Charge
[email protected]
## Contributors
TBD
## Version
1.0
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
