Hi Asitha, Don't we need APIs to update the existing Queues and Exchanges? This can be achieved by the *PUT *method.
Regards, Vinod On Fri, Jan 12, 2018 at 11:22 AM, Asitha Nanayakkara <asi...@wso2.com> wrote: > +1. At the moment we don't have that feature implemented within broker > core. I have created an issue [1] to track this. > > [1] https://github.com/wso2/message-broker/issues/142 > > > On Fri, Jan 12, 2018 at 10:02 AM, Hasitha Hiranya <hasit...@wso2.com> > wrote: > >> Hi Asitha, >> >> We need a API to purge a queue as well. >> >> Thanks >> >> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara <asi...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> Taking all the concerns discussed in to account I did some updates on >>> the design. >>> >>> With this design, I'll be exposing the exchanges, bindings, queues, and >>> consumers. This is to avoid confusion in coming up with a design to expose >>> topics (pub-sub pattern) as a first-class citizen (Since it is another >>> exchange within the broker). >>> >>> Following is the updated design >>> >>> >>> Base path /broker/v.1.0 >>> >>> >>> >>> >>> >>> >>> >>> Queues >>> >>> >>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable": >>> true, "autoDelete": false } >>> 6 List Queues/Topics GET /queues >>> 7 Get Queue Details GET /queues/{queueName} >>> 8 Delete Queue DELETE /queues/{queueName} >>> >>> >>> >>> >>> >>> >>> Subscriptions for a queue or topic >>> >>> >>> 9 List subscriptions for a destination GET /queues/{queueName}/consumers >>> 10 Get subscriber details GET /queues/{queueName}/consumers/ >>> {consumerTag} >>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag} >>> >>> >>> >>> >>> >>> >>> Exchanges >>> >>> >>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type": >>> "amq.direct", "durable": true } >>> 2 Get All exchanges GET /exchanges >>> 3 Get Exchange GET /exchanges/{exchangeName} >>> 4 Delete Exchange DELETE /exchanges/{exchangeName} >>> >>> >>> >>> >>> >>> >>> Bindings >>> >>> >>> >>> List bindings for exchange GET /exchanges/{exchangeName}/bindings >>> >>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey": >>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId = >>> 12345"} >>> >>> Delete binding DELETE /exchanges/{exchangeName}/bind >>> ings/{routingKey}/{queueName} >>> >>> >>> >>> >>> >>> >>> I have few concerns regarding deleting bindings. There is no unique key >>> for the binding hence I was thinking of something like following for the >>> delete binding (combination of routing key and queue name is unique) >>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}* >>> >>> What about using something like >>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234 >>> *for the delete? Can we consider a URI with query params as a unique >>> resource? >>> >>> I have attached the swagger file for the API as well. >>> >>> Regards, >>> Asitha >>> >>> >>> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera <asank...@wso2.com> >>> wrote: >>> >>>> Hi Asitha, >>>> >>>> I think it is better to say queues rather than destinations since the >>>> actions mean different things in queues and topics. For example, >>>> >>>> - Create >>>> - Queues - we can create the queue in broker core. This will be >>>> useful in assigning permissions >>>> - Topics - We can't do anything at broker code. Corresponding >>>> queues will depend on the subscription id if durable, random name if >>>> non >>>> durable. >>>> - Search >>>> - Queues - we can return queues matching the search criteria >>>> - Topics - It's hard to decide what to return since their can be >>>> unlimited number of options. >>>> - Delete >>>> - Queues - we can delete the specified queues >>>> - Topics - Again bit ambiguous what to delete. Maybe we can go >>>> through the matching bindings and delete the matching queues. My >>>> opinion is >>>> we should not do such a thing. >>>> >>>> Addtionally when we are desiging the REST API better if we dont expose >>>> functionalities that we are expecting to expose through the HTTP transport. >>>> I think the main objective in the first iteration should be to assist the >>>> users in debugging issues. Some information that a user might need is, >>>> >>>> - Queue list >>>> - Subscriptions for a given queue >>>> - Queue details - number messages etc >>>> - Message details >>>> - Permission details >>>> - Binding details of a queue. Will be very useful for topic >>>> scenarios. >>>> >>>> >>>> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe <eran...@wso2.com> >>>> wrote: >>>> >>>>> Hi Asitha, >>>>> >>>>> Thanks for the explanation. >>>>> >>>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara <asi...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Eranda, >>>>>> >>>>>> >>>>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe <eran...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Small addition to the Malintha's suggestion, I think a binding >>>>>>> should be a 3-tuple element <exchange-name, queue-name, routing-key> >>>>>>> >>>>>> For Bindings, we'll be using queue-name, routing-key, and filters. >>>>>> Exchange name can be inferred since we define bindings for a given >>>>>> exchange. >>>>>> >>>>> +1 >>>>> >>>>>> >>>>>>> Also, is it correct to use the term "destination" to generalize >>>>>>> queues and topics? AFAIK it's coming from the JMS world. >>>>>>> >>>>>> Yes, If we are going with a separate path for queues, outside >>>>>> /exchanges, we can have something like /queues. Used destinations to >>>>>> avoid >>>>>> the confusion with queues and topics. >>>>>> >>>>> Understood. +1 >>>>> I think its better to use the term "queue" if we are going to expose >>>>> this as a AMQP broker. >>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara <asi...@wso2.com >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> @Eranda: Thanks for pointing out the concern. We will be able to >>>>>>>> get over this concern by way of following the approach suggested by >>>>>>>> Malintha. >>>>>>>> >>>>>>>> @Malintha; Only concern I have with exposing GET /destinations is, >>>>>>>> we will expose all the queues, including temporary queues created for >>>>>>>> topics. Maybe we might be able to get over this by way of using >>>>>>>> filters. >>>>>>>> >>>>>>>> @Sanjeewa: We are planning to write this admin service using MSF4J >>>>>>>> and we are exposing this to do administrative tasks on the broker. >>>>>>>> Eventually the broker UI will use these servises as well. I will work >>>>>>>> on >>>>>>>> creating the swagger definitions based on these suggessions. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Asitha >>>>>>>> >>>>>>>> On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe < >>>>>>>> malint...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> A suggestion for Eranda's concern, for that I think we need to >>>>>>>>> remove the "exchanges" from the destinations APIs. >>>>>>>>> >>>>>>>>> One possible solution is: >>>>>>>>> >>>>>>>>> *Create Queue/Topic* >>>>>>>>> POST /destinations { "name": "queueName", "durable": true, >>>>>>>>> "autoDelete": false } >>>>>>>>> >>>>>>>>> *List Queues/Topics * >>>>>>>>> GET /destinations >>>>>>>>> >>>>>>>>> *Get Queue Details * >>>>>>>>> GET /destinations/{destinationName} >>>>>>>>> >>>>>>>>> *Delete Queue * >>>>>>>>> DELETE /destinations/{destinationName} >>>>>>>>> >>>>>>>>> *New APIs for adding/retrieving bindings:* >>>>>>>>> >>>>>>>>> *Add a new binding: (not sure about the name "binding" is >>>>>>>>> appropriate)* >>>>>>>>> POST /bindings >>>>>>>>> { >>>>>>>>> "exchangeName" : "exchange1", >>>>>>>>> "destinationName" : "destination1" >>>>>>>>> } >>>>>>>>> >>>>>>>>> *Get bindings for a particular exchange:* >>>>>>>>> GET /bindings?exchangeName="exchange1" => Provides a list of >>>>>>>>> bindings for the particular exchange >>>>>>>>> >>>>>>>>> During a discussion, Asitha mentioned about default exchange; If >>>>>>>>> exchangeName is not provided can we use it as its default value? >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda < >>>>>>>>> sanje...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara < >>>>>>>>>> asi...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Adding Harshak, Sanjeewa and Malinthaa >>>>>>>>>>> >>>>>>>>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara < >>>>>>>>>>> asi...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> In the new message broker implementation we are implementing >>>>>>>>>>>> broker semantics based on AMQP 0.9.1 specification. >>>>>>>>>>>> >>>>>>>>>>>> From an administrative operations perspective, we have >>>>>>>>>>>> identified following resources to be exposed through restful web >>>>>>>>>>>> services. >>>>>>>>>>>> >>>>>>>>>>>> - exchanges >>>>>>>>>>>> - queues >>>>>>>>>>>> - topics >>>>>>>>>>>> - consumers >>>>>>>>>>>> >>>>>>>>>>>> There are currently two types of exchange. Namely, >>>>>>>>>>>> >>>>>>>>>>>> - direct exchange - relates to mostly known queue scenarios >>>>>>>>>>>> - topic exchange - relates to topic scenarios (pub-sub >>>>>>>>>>>> pattern) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Queues and topics* >>>>>>>>>>>> >>>>>>>>>>>> Within the broker, there are only queues. These queues are >>>>>>>>>>>> bound to direct and topic exchanges. Depending on the bound >>>>>>>>>>>> exchange we >>>>>>>>>>>> perceive them as either pub-sub pattern or queue pattern. >>>>>>>>>>>> Therefore within the Admin API's we refer to either a queue or >>>>>>>>>>>> a topic as a *destination.* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Consumers* >>>>>>>>>>>> >>>>>>>>>>>> For each internal queue (a destination) there will be >>>>>>>>>>>> consumers. Messages are delivered to consumers in round robin >>>>>>>>>>>> manner. >>>>>>>>>>>> >>>>>>>>>>>> In topic scenario (pub-sub pattern) topic exchange will bind a >>>>>>>>>>>> separate queue (a destination) per each consumer with the same >>>>>>>>>>>> topic name. >>>>>>>>>>>> When a message is published it will get delivered to the set of >>>>>>>>>>>> queues with >>>>>>>>>>>> the matching topic and then to the relevant consumers on those >>>>>>>>>>>> queues >>>>>>>>>>>> >>>>>>>>>>>> Considering the above broker semantics we have come up with the >>>>>>>>>>>> following Admin API design for the broker >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Base path /broker/v.1.0 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Exchanges* >>>>>>>>>>>> *Method* >>>>>>>>>>>> *Path* >>>>>>>>>>>> *Payload* >>>>>>>>>>>> 1 Create Exchange POST /exchanges { "name": "exchangeName", >>>>>>>>>>>> "type": "amq.direct", "durable": true } >>>>>>>>>>>> 2 Get All exchanges GET /exchanges >>>>>>>>>>>> 3 Get Exchange GET /exchanges/{exchangeName} >>>>>>>>>>>> 4 Delete Exchange DELETE /exchanges/{exchangeName} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Destinations (Queues/Topics)* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5 Create Queue/Topic POST /exchanges/{exchangeName}/dest >>>>>>>>>>>> inations { "name": "queueName", "durable": true, "autoDelete": >>>>>>>>>>>> false } >>>>>>>>>>>> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations >>>>>>>>>>>> 7 Get Queue Details GET /exchanges/{exchangeName}/dest >>>>>>>>>>>> inations/{destinationName} >>>>>>>>>>>> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest >>>>>>>>>>>> inations/{destinationName} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Consumers (for a queue or topic)* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 9 List subscriptions for a destination GET >>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName}/con >>>>>>>>>>>> sumers >>>>>>>>>>>> 10 Get subscriber details GET /exchanges/{exchangeName}/dest >>>>>>>>>>>> inations/{destinationName}/consumers/{consumerTag} >>>>>>>>>>>> 11 Close subscriber DELETE /exchanges/{exchangeName}/dest >>>>>>>>>>>> inations/{destinationName}/consumers/{consumerTag} >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When retrieving a set of exchanges, destinations or consumers >>>>>>>>>>>> we will be able to filter the result set by way of using query >>>>>>>>>>>> parameters. >>>>>>>>>>>> >>>>>>>>>>> This API looks good and followed REST nature. I assume exchange >>>>>>>>>> name, destination name, consumer tag etc are unique. Then only we >>>>>>>>>> can build >>>>>>>>>> above mentioned resource model. >>>>>>>>>> Also do we need to let users to check the possibility of creating >>>>>>>>>> exchange, destination or consumer tag before we create it. Then we >>>>>>>>>> might >>>>>>>>>> need http head method as well. >>>>>>>>>> If you need to update que details then you have to use put as >>>>>>>>>> well. Ex: enable/disable auto delete after we create it first time. >>>>>>>>>> Also lets define proper response codes as well(201 to created, >>>>>>>>>> 202 accepted etc). >>>>>>>>>> >>>>>>>>>> What is the plan to expose this API to outside? Is it MSF4J? If >>>>>>>>>> that is the case you can start with swagger definition and move >>>>>>>>>> forward. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> sanjeewa. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Asitha >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>> Associate Technical Lead >>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>> Mob: +94 77 853 0682 <077%20853%200682> >>>>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>> >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Malintha Amarasinghe >>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>>> http://wso2.com/ >>>>>>>>> >>>>>>>>> Mobile : +94 712383306 <+94%2071%20238%203306> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>> Associate Technical Lead >>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Eranda Rajapakshe* >>>>>>> Software Engineer >>>>>>> WSO2 Inc. >>>>>>> Mobile : +94784822608 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>> Associate Technical Lead >>>>>> WSO2, Inc. <http://wso2.com/> >>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Eranda Rajapakshe* >>>>> Software Engineer >>>>> WSO2 Inc. >>>>> Mobile : +94784822608 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Asanka Abeyweera >>>> Associate Technical Lead >>>> WSO2 Inc. >>>> >>>> Phone: +94 712228648 <+94%2071%20222%208648> >>>> Blog: a5anka.github.io >>>> >>>> <https://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> *Asitha Nanayakkara* <http://asitha.github.io/> >>> Associate Technical Lead >>> WSO2, Inc. <http://wso2.com/> >>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Hasitha Abeykoon* >> Associate Technical Lead; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Asitha Nanayakkara* <http://asitha.github.io/> > Associate Technical Lead > WSO2, Inc. <http://wso2.com/> > Mob: +94 77 853 0682 <+94%2077%20853%200682> > [image: https://wso2.com/signature] <https://wso2.com/signature> > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Vinod Kavinda Senior Software Engineer *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* Mobile : +94 (0) 712 415544 Blog : http://soatechflicks.blogspot.com/ [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
