[jira] Commented: (QPID-3074) object creation and deletion via QMF for java broker

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

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

Robbie Gemmell commented on QPID-3074:
--------------------------------------

The method signature doesn't seem to allow (except for using different syntax between brokers) for specifying the virtualhost to create the objects in, which is required for the Java broker. Arguably the methods should be on the VirtualHost objects?

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