[jira] Commented: (QPID-3015) object creation and deletion via management

["Gordon Sim (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996426#comment-12996426 ] 

Gordon Sim commented on QPID-3015:
----------------------------------

Initial patch available for review: https://reviews.apache.org/r/436/

> object creation and deletion via management
> -------------------------------------------
>
>                 Key: QPID-3015
>                 URL: https://issues.apache.org/jira/browse/QPID-3015
>             Project: Qpid
>          Issue Type: New Feature
>          Components: C++ Broker, Java Broker
>    Affects Versions: 0.8
>            Reporter: Gordon Sim
>            Assignee: Gordon Sim
>             Fix For: 0.9
>
>
> ## 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

-- 
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-subscribe@qpid.apache.org