[
https://issues.apache.org/jira/browse/QPID-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-3074:
-----------------------------
Component/s: Java Broker
Description:
## 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
See also QPID-3015
was:
## 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
Fix Version/s: (was: 0.9)
Future
> object creation and deletion via QMF for java broker
> ----------------------------------------------------
>
> Key: QPID-3074
> URL: https://issues.apache.org/jira/browse/QPID-3074
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, Java Broker
> Affects Versions: 0.8
> Reporter: Gordon Sim
> Assignee: Gordon Sim
> Fix For: Future
>
>
> ## 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
> See also QPID-3015
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
