Hi Asitha, We need a API to purge a queue as well.
Thanks On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara <[email protected]> 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}/bindings/{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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> Hi Asitha, >>> >>> Thanks for the explanation. >>> >>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara <[email protected]> >>> wrote: >>> >>>> Hi Eranda, >>>> >>>> >>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe <[email protected]> >>>> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Adding Harshak, Sanjeewa and Malinthaa >>>>>>>>> >>>>>>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara < >>>>>>>>> [email protected]> 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}/destinations { >>>>>>>>>> "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 >>>>>> [email protected] >>>>>> 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 >>> [email protected] >>> 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 > [image: https://wso2.com/signature] <https://wso2.com/signature> > > > _______________________________________________ > Architecture mailing list > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
